Для чего я могу использовать POCO?

Question

Я прочитал несколько статей о POCO в рамке энтузиазма, но до сих пор не понимаю, для чего я могу его использовать. Как POCO может принести пользу моим проектам?

Answer 1

Стандарты POCO для «Обычный объект Clr Clar». Это относится к стилю архитектуры ORM, где вся работа по сохранению и загрузке данных из хранилища данных выполняется системой без самого объекта, зная, что с ней происходит. Это означает, что ORM может полностью поддерживать объекты, которые не были изменены каким-либо образом с учетом ORM. ORM, который поддерживает сохранение POCOs, не потребует, чтобы ваш класс наследовал от какой-либо конкретной базы, реализовал любой интерфейс или даже методы меток с любыми атрибутами.

Полное противоположное этому (иногда называемое объектами доступа к данным - или DAO) - это когда все хранилище обрабатывается самим объектом, оно точно знает, как сериализовать и хранить и как загружать себя, когда это необходимо. В этом случае объекты должны использоваться исключительно для передачи данных и не должны представлять какую-либо бизнес-логику системы.

В действительности это скорее спектр с этими двумя ситуациями с обоих концов. Многие ORM сидят где-то посередине, требуя, чтобы упорство выполнялось извне в класс, но часто также требовало, чтобы некоторые метаданные или интерфейсы были реализованы в классах, которые сохраняются, чтобы помочь в этом.

EF (v1) не поддерживает POCOs. Объекты должны реализовывать различные интерфейсы (для уведомления об изменениях значений свойств и т. Д.), Чтобы они сохранялись в рамках фреймворка. Я считаю, что есть addon frameworks, которые пытаются добавить поддержку POCO в EF, но я не знаю, насколько они успешны. У EF in .net 4.0 будет поддержка POCO.

POCO часто считается хорошим, поскольку он обеспечивает сильное разделение проблем. Вы можете определить свои объекты данных, чтобы иметь абсолютно нулевое знание механизма, который будет использоваться для их хранения. (Таким образом, это позволяет легко отключить механизм хранения для чего-то другого в будущем). Это также означает, что вам не нужно проектировать свои объекты данных с любыми соображениями для базы данных/фреймворка, которые используются для их хранения.

Answer 2

POCO - это просто «обычный объект CLR». Это стандартный класс, любой стандартный класс.

С точки зрения EF, люди ссылаются на возможность настройки EF для хранения собственных классов (не генерируемых непосредственно EF) в базу данных.

Answer 3

POCO - это классы, предназначенные для передачи данных в вашем приложении (т. Е. Перемещение данных с уровня данных на слой ui). Они также отделяют структуру вашего приложения от схемы вашей базы данных.

В небольших проектах это не имеет большого значения, но по мере развития проекта объектная модель (как вы проектируете свои POCOs) имеет тенденцию отклоняться от схемы базы данных.

Другие методы, которые обычно используются в .Net, это DataTables и DataSets. Обычно данные извлекаются с использованием имени столбца. Эти пары вы вводите имя столбца в своей базе данных. Если имя столбца изменяется в базе данных, вы разбиваете код.

Answer 4

POCO - это обычный класс, без добавленных интерфейсов или базовых классов, чтобы он работал с вашим уровнем базы данных (в этом контексте).

Преимущество: 1) никаких зависимостей от этого конкретного слоя базы данных, поэтому вы можете заменить его на лучшую (то есть NHibernate), не изменяя ничего, кроме уровня базы данных.

2) это упрощает модульное тестирование ваших классов.

3) нет кода котельной плиты, чтобы уведомлять, когда имущество изменилось и т. Д., Только простые геттеры и сеттеры.

Idealy ваши объекты домена загружаются из ОРМ, без этого объекта, имеющего иметь любое сказать в том, как он будет загружен, как изменения отслеживаются и как она сохраняется и т.д.

NHibernate делает очень хорошую работу в этом , единственным требованием является то, что вы должны сделать все свойства/методы виртуальными, это намного лучше, чем любая жесткая зависимость.