Entity Framework and DTO

Question

Im planning to use the Entities generated by the EF (POCO) in sending data to the client instead of creating DTOs? Is this a good practice? Basically, my EDMX file is on my DAL layer. So the UI will have direct access on my DAL. Thanks.

Answer 1

It depends on how close the client is to your object domain. If it is your client, then maybe - and indeed this is pretty much how ADO.NET Data Services (etc) work - directly exposing your model.

However, if the client is anything else I would suggest a dedicated DTO. In fact, I'd suggest it anyway ;p Otherwise, it gets somewhat complex:

• controlling the serialization details (what members? what names? what happens when we version it?)
• handling relation properties (it has an Orders member... but is that lazily loaded? do we want that?)
• merging incoming objects (for updates etc) back into the model
• suppressing any logic that you've added in setters, etc, during deserialization
• handling identity management if you get 2 separate copies of the same object back in a tree-based serializer like DataContractSerializer

In most cases, having a separate DTO makes most of these problems just go away

Answer 2

Basically, I don't think it's a good idea to send DAL objects to your interface, so I would use DTOs. To minimize the effort doing so I would take a look at an DTO generator, to generate DTO code which lets you convert from DAL object to DTO and vice versa.

EDIT: Sorry, didn't see you are using POCO. Have a look at this SO post

Answer 3

First of all, I believe you cannot use Entities generated by Entity Framework as return types in your Service, at least in a WCF Service.

But, why you would like to use entities all across your application? If you have a common architecture with a client-server structure, your client won't need all the information that an EntityObject has, like the ObjectContext where it is contained, the state on it, and lots of other info that your client not only won't use, but more important: don't have to know.

In that case you should use the DTO pattern, or other design pattern you think better that decouples the Server side from the Client Side. I believe DTO Pattern is the most widely used and recommended. If you are using Entity Framework you can go to http://entitiestodtos.codeplex.com , it is and AddIn for Visual Studio that I published, it is free and open source. It generates your DTOs from your Entity Framework Data Model (EDMX).

Regards, Fabian Fernandez

Answer 4

DTO is a good practice to minimise the amount of data you transfer over the wire to only include relevant fields. This is amongst other benefits. Checkout Automapper and the ProjectTo method which can automatically convert DAL to DTO and vice versa. ProjectTo under the bonnet will only select columns included in the configured mapping.

https://github.com/AutoMapper/AutoMapper/wiki/Queryable-Extensions

Answer 5

Using Entity Framework code first TT such as "EntityFramework Reverse POCO Generator" (https://marketplace.visualstudio.com/items?itemName=SimonHughes.EntityFrameworkReversePOCOGenerator) to generate Business Models associated to database tables schema in separate Business Entity Model library. The TT is able to be modified to include custom attributes (such as DataMember, Serializable) specially to WCF Entity.

This way could have both benefits of DTO and EF POCO. It could easily maintain consistence between Business Models Entities and database tables.

The reason is, for most cases, any time modify the database table structure, developer also needs to consistent the Business Model structure (DTO here). There is additional works to maintain mappers.

If the database access layer model (EF POCO here) loose coupling with DTO model. Developer will be very difficult to detect the potential error which cannot show in compilation time specially for maintaining existing enterprise level applications.

If we has additional custom properties required for Business Model entities, we are able to add partial class with custom properties.

We are still able to use mappers to convert EF POCO entity to DTO entity when it needed. But my point is, try to minimize abuse using mappers which just doing duplicate works compared with directly binding data to EF POCO model.

Since we can generate the EF POCO entities in separated Business Model library, DTO entity is able to stay with them in same Business Model library. Thus, developer has more flexibility to decide how to use them.