Need help using Entity Framework with CM

Topics: Getting Started
Sep 13, 2011 at 9:29 PM
Edited Sep 15, 2011 at 4:09 PM

I haven't been able to find instructions or samples showing Entity Framework used with CM in a WPF application. I'd greatly appreciate suggestions pointing me to a reference application or step by step instructions. I've posted a similar request on StackOverflow with no luck so far: . Note: My EDM will be created by dragging tables to the design surface to generate Entities. 

Is it possible to reap the benefits of CM if an EF Entity or the entire context is exposed as a property of the ViewModel? I'm hoping to simplify development with Caliburn.Micro conventions. Also, if I can avoid wrapping every field/property of an Entity that would save a lot of typing. Since Entities implement INotifyPropertyChanged is it necessary to call NotifyOfPropertyChange? Can I use EF in a manner similar to this: The blogger says he is able to use ActiveRecord with CM and "one line of code". Sounds pretty compelling. What do you think?

Edit: I've posted a related SO question here:

Thanks in advance.

Sep 21, 2011 at 12:15 AM
Edited Sep 21, 2011 at 12:17 AM

I apologize for the late reply.

Yes, it's perfectly fine to expose an instance of the entity (or a DTO, if your app communicates with remote services) in the VM.
Bindings should be obviously directed to the correct property path; the VM keeps the responsibility of loading***, validating and saving the entity.
Once you have the entity (implementing INotifyPropertyChanged implementation) on the client, there's no need to copy its data into the VM or wrap them into another structure.

(*** Another viable option is to load the entity from the caller, for example the VM representing a list of entities. )

That being said, I should also mention that this approach may have some (serious) drawbacks.
While it is fine from a "presentation pattern" point of view, it may lead (for non trivial applications) to some architectural and manteinance problems:
- entities are intended to represent business concerns, so they may have complex and nested structures, or espose non-primitive types; in this scenario, binding these objects (in both direction) to a View could quickly get very hard;
- unless you have an anaemic domain model, entities could expose behaviors instead of writable properties: this would prevent you to set properties from the UI through bindings;
- once you make the presentation side so tightly coupled with the entities, it gets hard to modify them; also, refactorings involving the bindings are usually more hard, since there's no compiler support for them.

Does it help?