CODEWITHSUNDEEP
c#entity-frameworkweb-services
Syed Osama Maruf
Syed Osama Maruf

Reputation: 1935

EF's POCO vs POCO better Data transfer Object?

I have a scenario in which I have some custom entities being used in a system (desktop) bound to its UI. I have shifted to Entity framework for the benefits it provides but the will continue to use the custom entities to bring data from UI as the custom entities are tightly coupled with the system. Now if I want to remove the dependence of the system on these custom entities like say I want to use my services from the web or any other platform what are my options from design perspective? I think that to remove dependence on custom entities I will have to use a Data Transfer Object say POCO. So should I use the POCO entities that EF provides for this purpose or write them separately?? Does it make sense. What should be my approach.

Upvotes: 2

Views: 561

Answers (2)

Matteo Mosca
Matteo Mosca

Reputation: 7448

A clean architecture will have a class library assembly (let's call it Common) containing your POCO objects. As per definition, POCO objects are persistence ignorant and contain no behaviour. They just represent your entities.

In a separate assembly (let's call it DataAccess) reference the Common assembly and create the mappings for EntityFramework, using the DbContext and EntityTypeConfiguration<T> classes. This obviously means that you won't use any EDMX file but create your mappings with the fluent interface, which is anyway the best way to use EF.

At this point you have reusable and decoupled objects in an assembly and your data access logic and mappings in another assembly.

On top of this you can throw an IoC container to keep things even more decoupled but I think it's a bit off topic.

Upvotes: 0

Mat&#237;as Fidemraizer
Mat&#237;as Fidemraizer

Reputation: 64923

Even if domain objects are implemented as POCO they're still domain objects and shouldn't be transfered to other physical tiers without using a DTO.

Think Entity Framework entities are proxies of your POCO-style domain objects in order to - for example - inject change tracking and lazy-loading. Also, a domain object might contain more data than required in some parts of your UI.

For example, you've implemented a grid with 3 columns: name, second name and age. You bind user profiles to the so-called grid, but your Profile domain object has also more properties, and this will transfer more data than required by your 3-columns-grid!

That's why you'll want to keep your domain in your domain, and data emitted by your services will serialize DTOs to cover your actual UI use cases and you won't be transferring fat objects over the wire, which might add extra costs to your organization (usually you pay for network usage in hosting environments), and obviously, serializing small objects is less intensive, isn't it?

Upvotes: 1

Related Questions