Ответ 1
Вместо того, чтобы называть их POCO, я предпочитаю называть их персистенцией неосведомленных объектов.
Поскольку их работа проста, им не нужно заботиться о том, для чего они используются или как они используются.
Лично я думаю, что POCO - это еще одно модное слово (например, Web 2.0 - не заставляйте меня начинать с этого) для открытого класса с простыми свойствами.
Я всегда использовал этот тип объектов для хранения в бизнес-состоянии.
Основное преимущество POCO действительно наблюдается, когда вы начинаете использовать такие вещи, как шаблон репозитория, ORM и инъекции зависимостей.
Другими словами, вы можете создать ORM (пусть говорят EF), который отвлекает данные откуда-то (db, веб-сервис и т.д.), а затем проектировать эти данные в объекты (POCO).
Эти объекты могут быть переданы далее в стек приложения на сервисный уровень, а затем на веб-уровень.
Затем, если в один прекрасный день вы решите переключиться на nHibernate, вам не придется касаться вашего POCO вообще, единственное, что нужно изменить, это ORM.
Следовательно, термин "упорство невежественное" - им все равно, для чего они используются или как они используются.
Итак, чтобы подвести итог, pro's:
- Позволяет простой механизм хранения данных, упрощает сериализацию/прохождение через слои
- Идет рука об руку с инъекцией Dependency, шаблоном репозитория и ORM. Гибкость.
- Минимизированная сложность и зависимости от других слоев. (более высокий уровень заботится только о POCO, POCO не заботится ни о чем). Свободная связь
- Простая тестируемость (для тестирования домена не требуется обрезание).
Надеюсь, что это поможет.