What is POCO & DTO?

Sooner or later after years of working as .NET developer ,without no aspirations to become architect :),  you get hit by this or that pure architecture jargon from your coworker (doing a lot of overnight reading and with aspiration to become architect :) ) or your boss.

Well it happens to once in a while.

So what is POCO?  " Hey, just do plain POCO's object no big deal, OK ? Got it?"

Been there ?

Yea, you try to hide stupid expression from your face and node with your head like you know what is it.
Few developers got guts to simple ask explanation from dude that speaks like that.

One thing you can be sure is that person thinks highly off you :) considering you have more than basic .NET architectural expirience.
POCO & DTO as terms that relay above simple old multi-layer architecture.
Yes they are both .NET classes. So what?

How many times have you decorated your objects for serialization?
Or how many times have you created partial classes to extend  LINQ or EF entities ?
Or writing highly custom WCF contracts and etc?

Well as average developer you do this and that with objects but you don't spend to much time naming what you do. You don't dwell in deeper understanding on what architecture principles lies EF or WCF.
We simply use it, right?

But than it comes to those 1 out of 100 situations. You use WCF, LINQ on everyday bases and BAM you run in to problem. Things don't work as you expected. Been there?
Suddenly its not enough to only know exposed API model - load, save, update, fetch bla bla.
As every normal dude you need to google solution, but how ?

That's my point, average developer today should get introduced to basic architectural terminology so you can google or ask your fellow architect and buy him a coffee.

Back to subject... Plain and simple POCO is good old OO class. You DO NOT decorate it with attributes.

In vision of accepted DDD (Domain driven design) approach it should be in very heart of your domain or business logic (onion architecture).
The catch is that you DO NOT make it dependant on your ORM for example.
And NO it is not just STATE or data container that is DTO.
POCO is full fledged sovereign object that describes in both behavior and content given real world problem.
And it does NOT KNOW how to save itself.

To repeat myself, POCO objects ideally should be in very heart of your project / domain you describe and not dependent on outer architecture that service them.

And what about DTO?
Now that is something you simply use to transfer data. They are flat. Way I see it put in .NET terms DTO are structures (which does not mean that DTO's should be coded as Structure ! ) . They only relay STATE or data NO BEHAVIOR

As stated bellow you could use them for example to service POCO's needs to "talk to world" by describing some data or frequently in web services as quick containers.

http://stackoverflow.com/questions/725348/poco-vs-dto