What is the best architectural choice for viewing aggregates of a constantly changing dataset?

Question

I need to decide on the optimal way to write a C# client application to view the dataset in a number of different views. One, some or all views may be visible at once and must be coherent. A simplified illustration of the dataset would be something like this, assume around 10000 items.

Based on this dataset a number of aggregates must be calculated, such as the sum of values for each ItemId and for each ClientId. The actual calculations are a bit more complicated, but assume that around 30 different aggregates must be calculated.

There will be around 10 clients that will view the data at any one time. Each user will decide if the data is continuously updated or refreshed automatically.

The data is stored in SQL Server 2008 R2 and all clients have access to this directly and are on the same LAN.

The UI needs to be non-blocking, so that new data can be read in the background and the active views refreshed when all aggregates have been calculated.

1. What architecture/technology/pattern is best suited to this sort of scenario?
2. Should I use WPF, Windows Forms or Silverlight?
3. Should the views be pre calculated on the server or should the client do this processing?
4. Should the client connect directly to the database or via a WCF service?

Answer 1

What architecture/technology/pattern is best suited to this sort of scenario?

As this sounds like mostly a read-only application and not something that will be doing data entry and validation, I'd probably opt for WPF (10 clients isn't much). Silverlight would be my second choice. Either tech will give you asyn callbacks. I've done both; WPF is going to be more responsive.

Should I use WPF, Windows Forms or Silverlight?

Avoid WinForms like the plague.

Should the views be pre calculated on the server or should the client do this processing?

It depends on how much work you want the database to do. Personally, I hate putting business logic in the database... I'd probably write a lightweight Service Facade over the DB, put my business logic in there, and then expose the results as a WCF Service to a WPF client (or as a RIA Service if I opted for Silverlight).

Should the client connect directly to the database or via a WCF service?

Connecting directly to the DB means you're going to HAVE to put all the business logic either in the DB in views/Sprocs or all of the calculations will have to be on the client (bad, IMO). Or spread out over the two (worse).

I, personally, would want all of the business logic in one place, on the server, so that clients who are fed the data are guaranteed to get the SAME results. I would not let the clients do calculations of the data.

EDIT: Also, having the clients do ANY sort of business calculations makes deployment and versioning more difficult. If you KNOW all of the business logic sits on a server, then all you have to do to update things is release a new version of the service. Then you don't care how many clients you have and who is on what version of the client app - you can still guarantee that the clients are getting the newest data via the one service.

I'd probably either construct views on the DB for the result sets (if the data calculations were simple and lent themselves to views easily) or I'd have a service on the server-side that did the calculations every X minutes and then cached those results (cache to other tables, or a different DB, or no-sql, whatever). Clients would then be free to pull data as often as they want, but the calculation of the data would actually be controlled by the service, not the clients. Letting the clients drive the updating of the data could be a mistake... The only way I'd find that acceptable really is if you put some kind of throttling mechanism on your messages so you could tell clients, "Don't ping me so fast for results, the server is lagging". Because the server needs to have some control over the load.

There's a lot to think about in this scenario, and these are just my initial thoughts.

Answer 2

I mostly agree with Barry: MVVM for design pattern, Silverlight makes sense, going through a Web service can also help with authorization / providing different features to different clients (even though this was not a specific requirement)

The only place I disagree is where the aggregations are made: I personally think that you should send the minimum amount of data necessary to the client, and let the clients do as many calculations as possible. For example, in your table, the 'Value' field looks like it's a simple product of the 'Quantity' and 'Price'. I don't really see the reason for calculating this in the database, then loading it to the web service, then passing it to the client, such that the client only displays the data. This means that your database is doing 95% of the work, but you can make the client do some work (10-15%) and reduce the workload on your database.

Answer 3

Unfortunately I think the answer for most of your questions is "It Depends".

1 - MVVM makes sense given your requirements of many views of the same sets of data.

2 - Which technology are you most familiar with now, and what is the timeframe of your application. If you're very familiar with WinForms and have a tight schedule that makes sense. If you're not and you have time learn, then Silverlight may make more sense. I'm kind of torn on WPF, since nowadays it seems more like Silverlight++ instead of the other way around. In other words, if you need to do a Line of Business app, pick Silverlight UNLESS theres a requirement that can only be fulfilled with WPF.

3 - The answer to this question depends on 2 things: How often is the data being updated and how complex/suited to SQL are the calculations. I would generally prefer to handle aggregating on the server side, but depending on the exact calculations you're performing that may or may not be feasible.

4 - This will really be made for you depending on your choice of technologies. Silverlight can't connect to the database directly, so you have to use a service. WinForms and WPF can directly connect to the database. Even so, going with a data access service can help if you find that having every client directly call the database could be a performance issue.

A lot of these decisions are trade offs, and you might not even know that you've traded something until it becomes an issue.

TLDR: It depends.