CODEWITHSUNDEEP
c#entity-framework
John Puopolo
John Puopolo

Reputation: 139

Using EF and Passing Data Through Application Layers

All,

We are using EF as our primary data access technology. Like many apps out there, we have a business objects/domain layer. This layers talks to our repository, which, in turn, talks to EF.

My question is: What is the best mechanism for passing the data back and forth to/from EF? Should we use the EF-generated entity classes (we did DB-first development, so we have entity classes that EF generated), create our own DTOs, use JSON or something else?

Of course, I could make an argument for each of these, as well as a counter-argument against them. I'm looking for opinions based on experience building a non-trivial application using a layered architecture and EF.

Thanks, John

Upvotes: 0

Views: 105

Answers (2)

Joe Ratzer
Joe Ratzer

Reputation: 18569

I would use POCOs and use them with EF. You can still do that with the DB first approach.

The main benefit is that your business objects will not be tied to any data access technology.

Your underlying storage mechanism can, and will, change but your POCOs remain. All that business logic is easily re-used and tested.

As you're looking for cons, then I would say it might take longer. However, that cost is well worth it.

Upvotes: 1

Thomas
Thomas

Reputation: 1197

With t4 templates I put the actual EF generated entities in a common project that is referenced by all other projects. I use the EF database first created models through the entire application (including use as view models). If I need to add additional properties to an entity that are not in the database I just extend the partial class of the entity in the common project. I have written dozens and large nTier applications using this model and its worked great.

Upvotes: 0

Related Questions