Для чего я могу использовать ПОСТЕПЕННО?
Википедия имеет большие рецензии, выдерживающие сравнение и дженерики Java/C# и Дженерики/C++ Java шаблоны. основная статья о Дженериках кажется немного нарушенной, но она действительно имеет некоторую хорошую информацию в нем.
4 ответа
Стандарты POCO для «Обычного старого объекта Clr». Это относится к стилю архитектуры ORM, в которой вся работа по сохранению и загрузке данных из хранилища данных выполняется системой, при этом сам объект не знает, что с ним происходит. Это означает, что ORM может полностью поддерживать простые объекты, которые никак не модифицировались с учетом ORM. ORM, поддерживающий постоянство POCO, не потребует от вас наследования вашего класса от какой-либо конкретной базы, реализации любого интерфейса или даже методов тегов с любыми атрибутами.
Полная противоположность этому (иногда известная как объекты доступа к данным - или DAO), когда все хранилище обрабатывается самим объектом, он точно знает, как сериализовать и сохранить себя и как загрузить себя, когда это необходимо. В этом случае объекты должны использоваться исключительно для передачи данных и не должны представлять какую-либо бизнес-логику системы.
На самом деле это скорее спектр с этими двумя ситуациями на обоих концах. Многие ORM находятся где-то посередине, требуя, чтобы персистентность обрабатывалась извне по отношению к классу, но часто также требует, чтобы некоторые метаданные или интерфейсы были реализованы в сохраняемых классах, чтобы помочь чему-то.
EF (v1) не поддерживает POCO. . Объекты должны реализовывать различные интерфейсы (для предоставления уведомлений об изменениях значений свойств и т. Д.), Чтобы их можно было сохранить в структуре. Я считаю, что существуют фреймворки , которые пытаются добавить поддержку POCO в EF, но я не знаю, насколько они успешны. EF в .net 4.0 будет иметь поддержку POCO.
POCO часто считают хорошим, потому что он позволяет четко разделить проблемы. Вы можете определить свои объекты данных так, чтобы они не знали о механизме, который будет использоваться для их хранения. (Таким образом, можно легко заменить механизм хранения на что-то другое в будущем). Это также означает, что вам не нужно проектировать свои объекты данных с учетом базы данных / инфраструктуры, которая используется для их хранения.
POCO - это просто «Обычный старый объект CLR». Это просто стандартный класс, любой стандартный класс.
В терминах EF люди имеют в виду возможность настроить EF для хранения ваших собственных классов (не генерируемых непосредственно EF) в базе данных.
POCO - это обычный класс, без добавленных интерфейсов или базовых классов, чтобы он работал с вашим уровнем базы данных (в данном контексте).
Преимущества: 1) нет зависимостей от этого конкретного уровня базы данных, поэтому вы можете заменить его на лучший (например, NHibernate), не изменяя ничего, кроме уровня базы данных.
2) это упрощает модульное тестирование ваших классов .
3) нет стандартного кода для уведомления об изменении свойства и т. Д. Только простые геттеры и сеттеры.
В идеале ваши объекты домена загружаются из ORM, и этот объект не должен иметь никакого отношения к тому, как он загружается , как отслеживаются изменения или как они сохраняются и т. д.
NHibernate отлично справляется с этим, единственное требование - вы должны сделать все свойства / методы виртуальными, это намного лучше, чем любая жесткая зависимость.
POCO - это классы, предназначенные для передачи данных в вашем приложении (т. Е. Перемещения данных с уровня данных на уровень пользовательского интерфейса). Они также отделяют структуру вашего приложения от схемы вашей базы данных.
Для небольших проектов это не имеет большого значения, но по мере роста проекта объектная модель (как вы проектируете свои POCO) имеет тенденцию отклоняться от схемы базы данных.
Другими методами, которые обычно используются в .Net, являются DataTables и DataSets. Обычно данные извлекаются с использованием имени столбца. Таким образом вы задаете имя столбца в своей базе данных. Если имя столбца в базе данных изменяется, код прерывается.