Plain Old Clr Object VS Data Transfer Object

Plain Old CLR Object vs Data Transfer Object

A POCO follows the rules of OOP. It should (but doesn't have to) have state and behavior. POCO comes from POJO, coined by Martin Fowler [anecdote here]. He used the term POJO as a way to make it more sexy to reject the framework heavy EJB implementations. POCO should be used in the same context in .Net. Don't let frameworks dictate your object's design.

A DTO's only purpose is to transfer state, and should have no behavior. See Martin Fowler's explanation of a DTO for an example of the use of this pattern.

Here's the difference: POCO describes an approach to programming (good old fashioned object oriented programming), where DTO is a pattern that is used to "transfer data" using objects.

While you can treat POCOs like DTOs, you run the risk of creating an anemic domain model if you do so. Additionally, there's a mismatch in structure, since DTOs should be designed to transfer data, not to represent the true structure of the business domain. The result of this is that DTOs tend to be more flat than your actual domain.

In a domain of any reasonable complexity, you're almost always better off creating separate domain POCOs and translating them to DTOs. DDD (domain driven design) defines the anti-corruption layer (another link here, but best thing to do is buy the book), which is a good structure that makes the segregation clear.

Want the difference between POCO and DTO in C#

learn to love the POCO, and make sure you don’t spread any misinformation about it being the same thing as a DTO. DTOs are simple data containers used for moving data between the layers of an application. POCOs are full-fledged business objects with the one requirement that they are Persistence Ignorant (no get or save methods)
BTW, Patrick, I read the POCO as a Lifestyle article, and I completely agree, that is a fantastic article.

YOu can check more details form here http://rlacovara.blogspot.com/2009/03/what-is-difference-between-dto-and-poco.html

Difference between Data transfer Object (DTO) & a dumb business object?

Maybe a little redundant, but I already typed it so hey ;)

To oversimplify (a lot), the business objects should have getter / setter methods, and the DTO should just have properties. The business objects need to obey you business rules, but the DTOs are just for transferring data; they don't need to obey any rules and should be designed to get data in and out of them as quickly as possible.

In a weakly-typed language like PHP DTOs are not always necessary as arbitrary properties can be given to generic objects on the fly. They can still be useful for documentation, though, and strongly-typed function parameters.

EF's POCO vs POCO better Data transfer Object?

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?

Difference between Entity and POCO

Plain Old CLR Object (POCO) has the same meaning as Plain Old Java Object (POJO).

The term was coined while Rebecca Parsons, Josh MacKenzie and I were
preparing for a talk at a conference in September 2000. In the talk we
were pointing out the many benefits of encoding business logic into
regular java objects rather than using Entity Beans. We wondered why
people were so against using regular objects in their systems and
concluded that it was because simple objects lacked a fancy name. So
we gave them one, and it's caught on very nicely.

by Martin Fowler

POCO is simply a regular object that has no references to any specific framework and does not follow their interfaces or restrictions. POCO classes are persistence ignorant objects that can be used with any ORM.

Entity is an object which has an identity and can be uniquely determined.

Entities represent domain model and domain logic. Usually they are designed as persistence ignorant POCO objects. But not every POCO object is an Entity. Value Objects are also designed as POCO objects and they are not Entities.

---

Related Topics