Using EF Entity as DTO Object

Question

Any opinion about this?

Answer 1

There is a podcast on .NET rocks that talks to Danny Simmons from the ADO.NET team. In it, he discusses using EF as basically a DTO to something like CSLA.NET business objects - he didn't see an issue with this, but said you are missing a lot of power of EF.

I have to agree - I think there are better, lighter ways to pass data around than using EF - but horses for courses and all that.

Answer 2

If you're restricting the entities to a one-to-one mapping for use as DTOs, I'd go with LINQ to SQL instead.

Both ORMS, though, were designed so that you can use them as full-blown business objects. Objects in neither framework have CRUD methods on them.

Answer 3

DON'T DO IT!!! That said, if your application is stupid-simple and not distributed in any way, it might work out alright. If you have any level of complexity, treat EF like a language-integrated database, not just language-integrated query access. You won't believe how big of a mess the ObjectContext will become until you get deep into your project, and then it will be too late. Same goes for LINQ to SQL.

Answer 4

I think it is a dirty option. If your application has business complexity I would use DTO and transform entities to dtos. You gain independency between your SIL (service interface layer) and your business layer. If you mix them, if you change your entities you are changing your messaging.

I like using three layers: - SIL (Service interface layer): it manages security and transforms dTO to entities and viceversa. - BLL (business layer): makes all the business, it contains entities, VO and the logic. All in a DDD fashion. - DAL: here I group all the DDBB stuff.

Regards.