POCO просто означает, что у ваших классов сущностей нет никакой логики постоянства. Это означает, что если у вас есть класс Order, он никогда не будет содержать методов, которые используются для получения данных из БД или сохранения данных в БД. У вас никогда не будет метода Order.GetById () или Order.Save () в POCO. Вы также не можете наследовать от базового класса, который содержит логику персистентности (где EF1 упал).
Класс вашего сущности будет иметь набор свойств, представляющих данные, и у вас, вероятно, будут некоторые методы проверки и, возможно, некоторые бизнес-методы, которые работают с данными заказа, но у вас не будет постоянных методов, которые получают или сохранить данные. Постоянство в архитектуре POCO обрабатывается отдельным классом, таким как Repository или DataService.
Если вы хотите узнать больше о том, что такое POCO, я написал пост в блоге, который дает более подробное объяснение здесь http://rlacovara.blogspot.com/2009/03/what-is-difference-between-dto-and-poco.html.
Причина, по которой вы много пишете о POCO и Entity Framework, заключается в том, что EF1 практически не позволяет реализовать настоящую архитектуру POCO. Многие разработчики, которые заботятся о таких вещах, как ORM, хотят использовать архитектуру POCO, так что это было большой проблемой. В EF4 и особенно в EF4 CodeFirst Microsoft внесла множество изменений, которые делают архитектуру POCO довольно простой в реализации.