以前、MIX 10のセッションビデオの中で「こういうのはPOCOで開発するんだよ」と解説してくれているのがあって（どのセッションかは失念）、そのときはたいして気にもしていなかったのだが、最近データアクセス層を作っているときに、おっ、ここはいっちょPOCOってみるか、と思いつき色々調べたらよく分からなかったので、今後のためにまとめておく。
（※間違っているかも知れないので話半分で聞いてください）
理解の元ネタは下記から収集。
POCO vs DTO at stackoverflow
POCO As A Lifestyle
What is the Difference Between a DTO and a POCO?
POCO vs DTOとなっているのは、一見POCOとDTOは似ているので、POCOのことを正確に理解していない人は「POCOってのはDTOと一緒だよ」とのたまうらしく、そちらの世界に導かれると「じゃぁなんでPOCOが必要なの？」って質問に答えられなくなるので、ホントのところはどうなってんだよ？という魂の叫びの表れである。
DTOはData Transfer Objectの略称で、DTOの唯一の目的は状態（データとかも含むのかな？）を他の層（とか他のアプリなど）へ渡すことにあって、OOP（オブジェクト指向プログラミング）的な振る舞い（特にビジネスロジック的なもの）を持つべきではない。必要な情報を渡すためだけの箱であって、それ以上でも以下でもない。
例：
// 正しいDTO
class PersonRightDTO
{
public string Name { get; set; }
public DateTime Birthday { get; set; }
}
// 正しくないDTO
class PersonWrongDTO
{
public string Name { get; set; }
public DateTime Birthday { get; set; }
public int GetAge() {
return // Calculate here.
}
}
POCOはPlain Old CLR Objectの略称で、これはPOJO（Plain Old Java Object）から来ている（POJOのWikiは
こちら）。で、POCOはPOJOと同じく、クラスの設計に.net frameworkをかませない（命令させない、規制させない）で行おう、という考え方。
なので、ここまでをまとめると、
POCOはシンプルなOOPへのアプローチ方法の説明で、
DTOはデータをどっかに渡すためのパターン、となる
で、ここから自分の解釈になるのだけど、こんな風になるのかな、と図解してみた。
ビジネスエンティティやドメインモデルと呼ばれるているオブジェクトがPOCOである。各層をつなぐ矢印があるけれど、その際に渡すオブジェクト（があるならば）はDTOでもPOCOでも良い。ドメインモデルと合致しないようなデータを渡すだけならば、それようにDTOを作って渡す方が良い。なので、DTOはPOCOよりもシンプルな構造になる。
最後に、POCOはPersistence Ignorance（PI：永続化に無知。変な日本語で申し訳ないけれど訳し方が分からない）でなければならない。つまり、Save()や、GetDataById()のような、永続性を持つロジック（データの読み込み、保存など）を実装してはならない。そのようなロジックはデータアクセス層に実装しよう。
ということでPOCOを使うと各層を明確に分離できるので、より良い構造になる。
以下にDDD（Domain Driven Design）を理解するのに良いと勧められていた本を紹介しておく。Google BooksにPreviewがあるので
そちらもどうぞ。
Domain-Driven Design: Tackling Complexity in the Heart of Software
