tags:

views:

6874

answers:

6
+38  Q: 

POCO vs DTO

POCO = Plain Old CLR (or better: Class) Object

DTO = Data Transfer Object

In this post there is a difference, but frankly most of the blogs I read describe POCO in the way DTO is defined: DTOs are simple data containers used for moving data between the layers of an application.

Are POCO and DTO the same thing?

(ps: look at this great article about POCO as a lifestyle)

+89  A: 

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 (better link here, but best thing to do is buy the book), which is a good structure that makes the segregation clear.

Michael Meadows
I know I referenced Martin Fowler a lot here, but he coined the term POJO, and wrote the book PoEAA that is the definitive reference for DTO.
Michael Meadows
nice freaking answer! If I could vote you up twice, I would. Very clear.
NotMyself
I'm not sure if a DTO should not have behaviors.Judging by Martin Fowler's diagram ,DTO could have behaviors.
Beatles1692
@Beatles1692, the methods depicted are serialization code. It's probably too broad of a statement to say "no behavior." How about "no business logic." Serialization code, and low level object stuff like hash code, equality, and tostring should be acceptable.
Michael Meadows
A: 

I think a DTO can be a POCO. DTO is more about the usage of the object while POCO is more of the style of the object (decoupled from architectural concepts).

One example where a POCO is something different than DTO is when you're talking about POCO's inside your domain model/business logic model, which is a nice OO representation of your problem domain. You could use the POCO's throughout the whole application, but this could have some undesirable side effect such a knowledge leaks. DTO's are for instance used from the Service Layer which the UI communicates with, the DTO's are flat representation of the data, and are only used for providing the UI with data, and communicating changes back to the service layer. The service layer is in charge of mapping the DTO's both ways to the POCO domain objects.

Update Martin Fowler said that this approach is a heavy road to take, and should only be taken if there is a significant mismatch between the domain layer and the user interface.

Davy Landman
@David Landman, the link you included is for the Local DTO pattern, which is when DTOs are used for transfer state within your system boundary. In these cases, you should be very careful, since within your system you should already have a well defined domain that can be shared. When transferring state across system boundaries, the DTO is hard to avoid and pretty appropriate in all cases.
Michael Meadows
@Michal Meadows, yes, the link does indeed talk about a different subset of problems. But I think in the case of transferring state across a system boundary you should use a translation service to map the POCO from one context to the POCO from other context. Or are you talking about bounderies on a system level?
Davy Landman
A: 

A primary use case for a DTO is in returning data from a web service. In this instance, POCO and DTO are equivalent. Any behavior in the POCO would be removed when it is returned from a web service, so it doesn't really matter whether or not it has behavior.

John Saunders
I think your answer misrepresents what happens a little. In the case of a web service, a proxy is generated based on the exposed state of an object. This means a DTO is created separate from the POCO that just happens to have the same public state as the POCO. It may seem subtle, but it's important. The reason is that even if the proxy is identical to the original, it's not actually constructed from the same class.
Michael Meadows
Uh, no. One uses a DTO to return / receive data between tiers, in this case, a web service. One chooses a DTO because it has only data, and no behavior. It's true that the proxy class will also likely be a DTO, and that if you had used a POCO class instead, that a proxy would have been created. But in this case, the POCO class is effectively a DTO, since its behavior will not translate. I still say use a DTO because you won't miss behavior that never existed.
John Saunders
@John Saunders, Sorry if I wasn't clearer. I'm not arguing with the validity of your argument, but instead with the semantics of it. ** To your point: A DTO is meant to protect your POCOs from what you describe. In order for this to happen, DTOs must be mapped to the POCO. In simple to moderately complex solutions, this may be overkill, and therefore you're correct.
Michael Meadows
** Semantically: Web services expose object state bags using WSDL. Proxies are generated from these. These cannot include behavior. If consuming a web service, the only relationship between your object and the exposed domain object is that it has the same public state created based on inspection.
Michael Meadows
@Michael: I have no idea what you're talking about. If you want that to change, then please post some citations or something. I've been using DTOs in web services for a while, and it was never in order to protect any POCO. It was in order to Transfer Data in an Object.
John Saunders
@John, I think you're overreacting. I'm saying you're right, but your wording is misleading. "In this case, POCO and DTO are equivalent." Semantically, that's not true. POCOs can be used as DTOs and vice versa, but that doesn't mean they're equivalent... no more than a car and pickup truck are equivalent, even though they can both be used to drive you to the grocery store. They have overlapping function, but you'd be hard pressed to find someone to tell you an insight is equivalent to an F350, even in the context of the grocery trip.
Michael Meadows
A: 

here is the general rule: DTO==evil and indicator of over-engineered software. POCO==good. 'enterprise' patterns have destroyed the brains of a lot of people in the J2EE world. please don't repeat the mistake in .NET land.

drscroogemcduck
Could you elaborate, please? DTO are required when returning data from a web service, in order to avoid implementation and platform specifics in the contract.
John Saunders
Yes, John DTO's are designed for what you say and work well. But unfortunately they often get used when not required in single tier web apps and have little value.
Craig
I think, @drscroogemcduck, that maybe you dislike DTOs because they're used as a first resort rather than a last resort, but they're not inherently evil... no more so than the _infamous_ singleton or factory patterns. What is evil are the architects who shove frameworks down developers' throats that force them to make DTOs for everything. For what they do, transferring data, DTOs (if done prudently) are the perfect fit.
Michael Meadows
+10  A: 

It's probably redundant for me to contribute since I already stated my position in my blog article, but the final paragraph of that article kind of sums things up:

So, in conclusion, 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). Lastly, if you haven’t checked out Jimmy Nilsson’s book yet, pick it up from your local university stacks. It has examples in C# and it’s a great read.

BTW, Patrick I read the POCO as a Lifestyle article, and I completely agree, that is a fantastic article. It's actually a section from the Jimmy Nilsson book that I recommended. I had no idea that it was available online. His book really is the best source of information I've found on POCO / DTO / Repository / and other DDD development practices.

Thanks! This is the first clear answer I've read!!!
John
Link to blog article: http://rlacovara.blogspot.com/2009/03/what-is-difference-between-dto-and-poco.html
Jamie Ide
+1  A: 

POCO is simply an object that does not take a dependency on an external framework. It is PLAIN.

Whether a POCO has behaviour or not is immaterial.

A DTO maybe POCO as may a domain object (which would typically be rich in behaviour)

Typically DTOs are more likely to take dependencies on external frameworks (eg attributes) for serialisation purposes as typically they exit at the boundary of a system.

In typical Onion style architectures (often used within a broadly DDD approach) the domain layer is placed at the centre and so it's objects should not at this point have dependencies outside of that layer.

Neil