domain driven design using Entity framework 4

Question

I have read some posts which discuss about how to use EF entities as business objects

Using Entity Framework entities as business objects?

but doesn't this make the design of the business objects dependent on the data model? Is this the right practice for enterprise applications? shouldn't the domain and data model be independent and changes in one shouldn't affect the other? if I choose to keep them separate, then do I need to create another layer to populate the business objects from the EF entities? if I have both custom business objects and the EF entities, which one is used to transfer data between layers (including all the way to UI)? is there an architectural pattern for this? It would be useful if there is a sample application that demonstrates these concepts (not simply a demo version, suitable to use in an enterprise application).

This link explains the problem clearly

http://msdn.microsoft.com/en-us/magazine/dd882510.aspx#id0420099

Answer 1

This one is a contentious one and it totally depends on how far you want to architect your app...

There are strong opinions that advocate using DTO/POCO (Plain Old CLR Obects) and indeed you can use EF to generate DTO's to achieve such a thing. This is kind of the Rolls-Royce with regard to architecture... The key advantage is that you decouple your business logic from your data access and then in theory enable you to switch to the latest and greatest ORM in the future. The disadvantage being that (as you said in your question) you need a mapping service to translate between the two layers as well as the fact that you're essentially ending up with multiple classes to represent the same piece of data.

Generally, the use of DTO/POCO is not advocated for small/medium because of the added code bloat, however, for larger projects the separations of concerns can be beneficial despite the added volumes coding. Enterprise application or not, I think you need to consider the reality of whether or not you'd ever want to switch out your ORM tool (that is, EF).

Additionally, I think the EF generated classes are sufficiently simple enough already and hide the majority of data access code in the ".designer.cs" and even then the bulk of it with declarative attributes.

So my personal opinion, albeit probably a controversial one, is to agree with the accepted answer in the linked post and use the entity framework entities as business objects. I would also agree that this is the intent behind EF (and most ORM's) in the first place...

Have a good look through this series of articles for more information.

Answer 2

It depends on how loosly coupled you want / need to be.

Take for example a WPF/MVVM app that talks to a Service via WCF and stores data using EF. Then if you go all the way you have the following:

On the client:

• View
• ViewModel
• Model

Between client and Server:

• Data transfer object

On the server:

• Business Entities
• EF Entities

With mapping code between each layer. This can be a lot of work and duplication between objects. It may not be practical too have so many layers. We try to combine them where possible, for example can the DTO also be the model?

Using partial classes you can add functionality to EF classes that will not be deleted if the model is regenerated. So you could use then as your business entities.

I would not use them as DTO's for the following reasons:

• A change in the database could impact many systems
• Non MS clients could be using your services