Стандарты POCO для "Plain Old Clr Object". Это относится к стилю архитектуры ORM, где вся работа по сохранению и загрузке данных из хранилища данных выполняется системой, причем сам объект не знает, что с ним происходит. Это означает, что ORM может поддерживать полностью обычные объекты, которые не были изменены каким-либо образом с учетом ORM. ORM, поддерживающий постоянство POCO, не потребует от вас наследования вашего класса от какой-либо конкретной базы, реализации любого интерфейса или даже тегирования методов с любыми атрибутами.
Полная противоположность этому (иногда известная как объекты доступа к данным - или DAO) состоит в том, что когда все хранилище обрабатывается самим объектом, он точно знает, как сериализовать и хранить себя и как загружать себя при необходимости. В этом случае объекты должны использоваться исключительно для передачи данных и не должны представлять какую-либо бизнес-логику системы.
На самом деле это больше спектр с этими двумя ситуациями на обоих концах. Многие ORM находятся где-то посередине, требуя, чтобы постоянство обрабатывалось внешне по отношению к классу, но часто также требуется, чтобы некоторые метаданные или интерфейсы, реализованные в классах, сохранялись, чтобы помочь вещам.
EF (v1) не поддерживает POCO. Объекты должны реализовывать различные интерфейсы (чтобы обеспечить уведомление об изменениях значений свойств и т. Д.), Чтобы быть устойчивой в рамках. Я считаю, что существуют аддон-каркасы , которые пытаются добавить поддержку POCO в EF, но я не знаю, насколько они успешны. EF в .net 4.0 будет иметь поддержку POCO.
POCO часто считается хорошим, потому что он допускает сильное разделение интересов. Вы можете определить свои объекты данных, чтобы иметь абсолютно нулевые знания о механизме, который будет использоваться для их хранения. (Таким образом, в будущем легко будет отключить механизм хранения для чего-то другого). Это также означает, что вам не нужно проектировать объекты данных с учетом базы данных / инфраструктуры, которая используется для их хранения.