Entity Framework and MVVM

[Erick Thompson]

I am playing around with implementing an MVVM WPF application with the Entity Framework as the data portion. I can see a number of ways do this, and I'm not seeing a clear decision as to which approach is the best.

 

Use EF objects as both Model and Repository

This seems like these easiest solution in terms of amount of code that needs to be written. I would basically expose the ObjectQueries to the ViewModel for loading content, and have a single ObjectContext for the application.

• On the minus side, the repository is contained within the model, and it exposes the ability to load any random entities from the ViewModel.
• On the plus side, it allows me to contain the ObjectContext in one location, so I will only have one instance of it, avoiding some problems with having to use the database as the master state container.
• On the minus side, having only ObjectContext makes it much harder to have units of work that can be easily cancelled (which I generally do by having a new ObjectContext to represent a unit of work).

Use EF objects as Model

This solution would use the generated Entity classes as the model, but use an explicit ModelView to load/save/manage the Entities. This requires that I write a lot of glue code to sync between my collections (e.g., CustomerRepository with List<Customers> and ObjectContext collection). Or, I could tear out the ObjectQueries from the generate code, and create new ones for the ModelView (exposing the correct queries for the view) along with explicit ObjectContexts for each repository.

• On the plus side, I can use the existing EF generated objects, and the ObjectQuery infrastructure.
• On the minus side, I will need a distinct build step to tear apart the Entities from the ObjectQueries.
• On the minus side, I will need to sync between different repositories, or use the DB as the master state location.

Use EF as a DAL

This is the least appealing option, as it requires a lot of code. I would write new classes for each entity in the model, and then use the EF as a DAL, marshalling between the EF Entities and my own Entities. This seems to require a lot of work and glue code, and doesn't have a lot of benefits aside from a very clean separation of model from everything else.

• On the plus side, this is a very clean solution.
• On the minus side, I have to write a lot of code and lose the benefits of composable queries (unless I am willing to write even more glue code).

Am I missing another option? What have other people done in terms of MVVM applications using the Entity Framework?

 

Thanks,

Erick

[Glenn Block]

Hi Erick

 

Whether you use Entity Framework, NH or datasets, it should not impact the ViewModel. ViewModels should be completely agnostic from the mechanism for data retrieval, this is part of separating out concerns and responsibilities:

 

1.       I would definitely not use the entities as the ViewModel. View Models are supposed to be purely for presentation. They may expose the underlying model as properties on  the ViewModel, but that is a completely different story.

2.       In terms of querying, I would also not recommend binding the VM in any way to your data retrieval in that it more tightly couples the implementation, and also greatly impacts testability. Instead you should inject a service / controller into the VM on construction that it can use for data retrieval. The implementation of that service should call to EF under the hood. I would also not let EF semantics bleed into the interface of the service, instead it should have fine-grained, specific accessors for the data such as GetCustomer, GetOrderItems….etc.

 

If you look in the patterns & practices Composite WPF guidance (www.microsoft.com/CompositeWPF), you  will see some good examples of implementing MVVM in the manner I described. They are not using EF, but the approach of getting entity data through services is in the Stock Trader Reference Implementation.

 

Happy to chat with you more on this.

 

Glenn

[Erick Thompson]

Thanks for the quick reply Glenn.

 

Right now, what I'm thinking about is having the EF Entities be the model, and then have a set of Repository classes for each Entity/ViewModel (as appropriate). The problems that I can see is that this doesn't provide enforced separation between the Model and the ViewModel (the ObjectQueries are all public), and that it makes the Entities a little harder to test, as EF Entities aren't very mockable. It seems like a nice balence, but definitely not perfect.

 

The problem that I have with the composite WPF framework, as well as all the other examples with MVP, MVVM and so on is that they generally use pure CLR classes for business objects. This is great, but it just doesn't fit with the current data frameworks, which all bleed data semantics into the business layer. It's getting that across that bridge that causes me headaches.

 

Thanks,

Erick

[Glenn Block]

Hi Erick

 

So the ObjectQueries are static? You can enforce separation between the VM and the model by using services as I mentioned which wrap the data access, unless I am missing something. If  you are concerned about testability, create DTOs to pass back from the service, rather than passing back EF entities at all.

 

As far as Composite WPF, the reason why we didn't use EF, is because the focus is completely on the Composte app / UI aspects rather than the domain layer. Basically they are DTOs. Regardless though, I don't see how it doesn't fit as again you can encapsulate your data framework of choice so that it does not bleed in.

 

Glenn

[Erick Thompson]

Glenn,

 

Using the services approach that you mention does keep the data framework encapsulated. The problem is that EF Entities carry around a lot of state (current state of the object, the set to which it belongs, keys, etc).

 

One major concern is around testablility, and I quickly realized that the only way I could acheive this is via DTOs, and keep the EF Entities internal to the model. The problem with this approach is that it is a lot more code, work, testing, etc. I was hoping that someone smarter than me had figured out a good way to use EF Entities with a MVVM/Composite WPF style application without resorting to the DTO style of separation. I feel like there is a solution here, but I'm not quite getting it at yet. My gut is telling me that it will require using a different template for the code-gen portion of an EF based system.

 

Thanks,

ERick