.NET Entity Framework

Is it wrong to use generated entities from Entity Framework as business entities? Is it better to write a secondary wrapper around Entity Framework objects that I would then traverse between layers?

For example, write my own POCO entity that takes one of my EFPerson generated Entity Framework to initialize the POCO Person entity?

+1


a source to share


2 answers


I don't understand why this would be bad practice. This can be inconvenient according to how you intend to use your EF objects.

I have partial classes for implementing BIZ logic in EF objects using an interface to provide an abstraction layer.

eg.



public partial class Client : IClient
{
   void DoSomething();
}

// then an EF generated object ...
public partial class Client
{
 // ...
}

      

My only problem I am facing is object serialization. In my case, serialization to JSON using WCF. This is not possible without creating an intermediate DTO as a discrete class / object or anonymous type.

If you are interested in serialization take a look at my other question: Serialize Entity Framework Objects to JSON

+2


a source


While some people tend to wrap Entity Framework classes in their own business objects, I usually suggest not to.

I realize this improves the separation of business logic and data access, but I think it's usually not worth the overhead of duplicating all entity types.



What is the purpose of an OR display device? It is designed to persist business objects without having to create a complex data access layer manually mapping objects to the database. If you close the Entity Framework classes, you will only be using half of the resulting convenience.

Finally, the relationship between data access and business logic is not tight with partial classes. I recently changed a project involving about 30 entities from Entity Framework to LINQ to SQL in just a few hours without major issues.

+4


a source







All Articles