查看不断变化的数据集的聚合的最佳架构选择是什么？

Question

我需要决定编写C＃客户端应用程序以在多个不同视图中查看数据集的最佳方式。一个，部分或全部视图可以同时显示，并且必须一致。 数据集的简化图示就是这样，假设大约10000个项目。

基于此数据集，必须计算多个聚合，例如每个ItemId和每个ClientId的值的总和。实际计算有点复杂，但假设必须计算大约30个不同的聚合。

每次将有大约10个客户端查看数据。每个用户将决定数据是否自动持续更新或刷新。

数据存储在SQL Server 2008 R2中，所有客户端都可以直接访问，并且位于同一个LAN上。

UI必须是非阻塞的，以便可以在后台读取新数据，并在计算完所有聚合后刷新活动视图。

1. 哪种架构/技术/模式最适合这种情况？
2. 我应该使用WPF，Windows窗体还是Silverlight？
3. 是否应在服务器上预先计算视图，或者客户端是否应进行此处理？
4. 客户端应该直接连接到数据库还是通过WCF服务？

Answer 1

不幸的是，我认为你的大多数问题的答案都是“它取决于”。

1 - 根据您对同一组数据的许多视图的要求，MVVM是有意义的。

2 - 您现在最熟悉哪种技术，以及您的应用程序的时间范围。如果你对WinForms非常熟悉并且有一个有意义的紧凑时间表。如果你不是，并且你有时间学习，那么Silverlight可能更有意义。我对WPF很感兴趣，因为现在它看起来更像是Silverlight ++，而不是相反。换句话说，如果您需要创建业务线应用，请选择Silverlight UNLESS ，这是一项只能通过WPF实现的要求。

3 - 这个问题的答案取决于两件事：数据的更新频率以及SQL的复杂/适合程度。我通常更喜欢在服务器端处理聚合，但取决于您执行的确切计算，这可能是可行的，也可能是不可行的。

4 - 根据您选择的技术，这将真正为您服务。 Silverlight无法直接连接到数据库，因此您必须使用服务。 WinForms和WPF可以直接连接到数据库。即便如此，如果您发现让每个客户端直接调用数据库都可能是性能问题，那么使用数据访问服务可能会有所帮助。

很多这些决定都是权衡利弊，你可能甚至不知道自己已经交易过东西，直到它成为一个问题。

TLDR：这取决于。

Answer 2

我主要同意Barry：MVVM的设计模式，Silverlight有意义，通过Web服务也可以帮助授权/为不同的客户提供不同的功能（即使这不是特定的要求）

我不同意的唯一地方是聚合的位置：我个人认为您应该向客户端发送最小数量的数据，并让客户尽可能多地进行计算。例如，在您的表格中，“价值”字段看起来像是“数量”和“价格”的简单产品。我没有真正看到在数据库中计算它的原因，然后将其加载到Web服务，然后将其传递给客户端，以便客户端只显示数据。这意味着您的数据库正在完成95％的工作，但您可以让客户端完成一些工作（10-15％）并减少数据库的工作量。

Answer 3

哪种架构/技术/模式最适合这种情况？

由于这听起来像是一个只读应用程序，而不是将要进行数据输入和验证的东西，我可能会选择WPF（10个客户端并不多）。 Silverlight将是我的第二选择。技术人员都会给你asyn回调。我做过两件事; WPF将更具响应性。

我应该使用WPF，Windows窗体还是Silverlight？

避免像瘟疫那样的WinForms。

是否应在服务器上预先计算视图，或者客户端是否应进行此处理？

这取决于您希望数据库完成多少工作。就个人而言，我讨厌将业务逻辑放在数据库中......我可能会在数据库上编写一个轻量级的服务外观，将我的业务逻辑放在那里，然后将结果作为WCF服务公开给WPF客户端（或者作为一个RIA服务，如果我选择Silverlight）。

客户端应该直接连接到数据库还是通过WCF服务？

直接连接到数据库意味着您必须将所有业务逻辑放在视图/ Sprocs中的DB中，否则所有计算都必须在客户端上（坏，IMO）。或分散在两个（更糟）。

我个人希望将所有业务逻辑放在服务器上的一个位置，以便保证提供数据的客户端获得相同的结果。我不会让客户做数据的计算。

编辑：此外，让客户端进行任何类型的业务计算都会使部署和版本控制变得更加困难。如果您知道所有业务逻辑都位于服务器上，那么您只需要更新内容即可发布新版本的服务。那么你不关心你有多少客户端以及谁在什么版本的客户端应用程序上 - 你仍然可以保证客户端通过一个服务获得最新的数据。

我可能要么在数据库上为结果集构建视图（如果数据计算很简单并且很容易将它们自己提供给视图），或者我在服务器端有一个服务，它每隔X分钟进行一次计算然后缓存那些结果（缓存到其他表，或不同的DB，或无sql，无论如何）。然后，客户可以根据需要随意提取数据，但数据的计算实际上将由服务而不是客户端控制。让客户驱动数据更新可能是一个错误......我发现可接受的唯一方法就是你在邮件上加入某种限制机制，这样你就可以告诉客户，“别管我如此快速的结果，服务器滞后“。因为服务器需要对负载进行一些控制。

在这种情况下需要考虑很多，这些只是我最初的想法。