I am an experienced Windows Forms developer and am taking the plunge into WPF and MVVM. Still confused on some things but learning. I have been looking/reviewing several MVVM frameworks and I am very impressed (as are others) with Catel. I am still trying
to get a handle around how to use something like Linq to Sql to generate my model and tie that into the Catel framework. Geert mentions using LLBLGenPro. How well does that work? How does it work? Does it decorate the generated code with the Serialization,
PropertyData, GetValue, SetValue, etc.? I want to try to avoid coding the "move" data from the database to the model, and from the model to the viewmodel (which is handled through the ViewModelToModel attribute as I understand it). Any thoughts
or help would be appreciated.
Jan 20, 2011 at 7:42 AM
First of all, great to hear that you are taking a look at WPF. At first, it might be useless and bring nothing but trouble compared to WinForms. But don't give up, once you find out the power of WPF, you'll never want to go back to WinForms again.
Anyway, there are several things you should consider, and everyone has it's own opinion on what I am going to subscribe. Just pick the one you like or experience with all of them to see what you like most.
DAL and Business Layer "combined"
When I use L2S, I also use LLBLGen to generate the entity classes. However, this is just generated code, and you should be able to write (or generate) this code via the L2S tools by yourself. I always generate partial classes (Customer.g.cs and Customer.cs),
and thus have a DAL (the actual definition of the properties, etc, which is Customer.g.cs), and part of the business layer (such as the errors for IDataErrorInfo, which is Customer.cs). Thus, I like to combine the DAL and business layer together for the entity
logic. I still separate them (via the g.cs and cs files). If I want to change to another database system, I can still use my partial cs files which include the same business rules.
If you like this approach, the entity is the model used in MVVM.
DAL and Business Layer "separated"
Some people want to change the RDBMS (Relational DataBase Management System) on-the-fly. In this case, it is very hard to combine the DAL and BL together. Some other people just want it separated for the sake of Separation of Concerns (SoC).
In this case, you will have to create an intermediate entity class which will serve as the model. It gives you more flexibility because you can change the RDBMS without breaking your business rules, especially if you can interact with the database in the same
manner, but I hardly doubt this (because LLBLGen uses IEntity.Save, L2S uses a DataContext, etc).
If you like this approach, the entity is not the model, but only responsible for the database communication. You will need to create an additional business layer defining an object that holds the business rules, and this will be the model used in MVVM.
A short note on LLBLGen
I use LLBLGen because when I started .NET development, there weren't many good ORM mappers available. The strong thing about LLBLGen is that you can choose between Servicing (specific for 1 db type) of Adapter (requires some more coding, but
allows you to support multiple db types with the same code). So, on a large project, we had to deal with MySQL. We created the DAL and the business rules for the entities in the project. Finally we convinced the manager to move the MS SQL, and we only needed
to re-generate the same entities for MS SQL and we were done.
So, I like LLBLGen, but there are alternatives like NHibernate, Entity Framework, and probably some more. What I miss in LLBLGen (I still use 2.6) is that it doesn't generate interfaces for the entities (much easier for unit testing). However, you can customize
all the templates in LLBLGen so eventually add these yourselves (we added the entity.g.cs partial class ourselves as well).