What are the best characteristics of a datalayer framework for WPF/MVVM applications?

Question

I am creating a WPF/MVVM framework which generates the code for the model classes.

I'm planning to have for each database-table/web-service (e.g. "Customers") two model classes:

• a singular model class (e.g. "Customer")
• and a plural model class (e.g. "Customers")

The singular model class has all of its properties (FirstName, LastName, etc.) plus all of it methods which make sense for a singular instance, e.g. Save(), Delete(), CalculateSalary(), etc.

The plural model class has a collection of singular model objects, plus the same methods since you would want to also perform on a group of singular objects, e.g. Save(), Delete(), CalculateSalary(), but also particular methods such as Sort(), and methods that made it very easy to certain groups, e.g. LoadAllGoldCustomers(), or even LoadWithSql(string sql), etc.

I've done a framework like this before (PHP) and it made for very easy to write and understand code like this:

Customers customers = new Customers("all");
customers.CalculateSalary();

A couple inherited classes (Item and Items) took most of the code out of the individual singular and plural classes for each database table, which made a very clean environment to program in.

However, I have rarely seen other applications do this singular/plural model class split. Instead, there is almost always just one class for each database table, e.g. Customer and this class has any plural methods necessary, e.g. GetCustomers(string sql), etc.

I just noticed in the WPF Model-View-ViewModel Toolkit 0.1 walkthrough, they have you make two models their "Models" directory two classes:

• Customer.cs (fields only)
• CustomersDataSource.cs (one List Load() method)

Which seems to be a similar concept, just that the "plural" class is called a DataSource.

So now I am about to make another framework based in WPF/MVVM and can decide how I want to structure the model classes. I want the framework to be:

• clear and easy to program against from the ViewModel, hence the clear separation of singular and plural model classes, you should just have to instantiate a singular or plural class and call a method on it and you have your data.
• fit in well with the MVVM pattern (which I understand means to keep as simple as possible, just have properties and methods that the ViewModel can call, but implement no WPF-specific features such as INotifyProperityChanged)
• want my datalayer to sit above any datasource, so if I use LINQ-to-SQL, I still call my own model classes, and if I want to switch to saving in Oracle, I write a lower data adapter layer for my classes to interact with that.
• take advantage of LINQ in the best way possible

I would appreciate feedback from those who have developed datalayers for frameworks especially using WPF/MVVM/Composite Application Library and what characteristics you found worked best, or if you have worked with other frameworks such as CSLA, Subsonic, etc. Also, any experience or ideas on how LINQ changes/simplifies building a datalayer structure. Thanks.

Answer 1

Wow. That's a hard question to answer without having a day to sit down and speak with you. But here goes a shortened version anyway.

First, attempting to port a framework or any characteristics of that framework from one language to another seems like it maybe be trying to shove a square peg in a round hole. While I don't doubt that features (e.g. customer and customers) can be ported, I could certainly argue that they shouldn't be ported. Sticking with the customer.CalculateSalary exmaple, you could use .NET and create an extension method for IEnumerable that did the same thing, eliminating the need for that Customers class. I realize you may have other features as well, but that's just an example. Another example is using LINQ to sort IEnumerable.

Second, I have personally found that having the persistence methods (e.g. Save, Delete, etc.) inside of the object doesn't work well in a large system, particularly when dealing with WCF. It seems to work better in these scenarios to use some type of repository later, which seems like it would also play well with your point of switching to Oracle in the middle of development.

I also want to totally disagree with you on the bullet about fitting well into MVVM. To me, the view model is the glue between the model and the view. It is not only likely that the view model would need to know about the view (hence, WPF specific features), but desired that it know about it. ICommand is a critical interface for the view model to know about, and is one of the WPF-y assemblies (WindowsBase, PresentationCore, PresentationFramework, can't remember which). Also, INotifyPropertyChanged is also critical to data binding and should be implemented in all view models, and has nothing to do with WPF (comes from System.ComponentModel i think?).

That's my two cents. Again, it's really difficult to explain this in a short response to your question. I would recommend using the pattern for a while before making a framework for it. Good luck!