Отсутствует. Точка. Все преимущества, которые люди любят бросать, - это преимущества, которые не важны в большом масштабе картины. Я скорее предпочитаю сильный базовый класс для объектов сущностей, который на самом деле содержит много интегрированного кода (например, генерирует события изменения свойств при изменении свойств), чем сам пишет все это. Обратите внимание, что я написал (в то время коммерчески доступный) ORM для .NET еще до того, как «LINQ» или «ObjectSpaces» появились. Я использовал O / R mappers вот уже 15 лет, и никогда не встречал случая, когда POCO действительно был чем-то, что стоило возможных проблем.
Тем не менее, атрибуты МОГУТ быть плохими по другим причинам. В настоящее время я предпочитаю использовать подход Fluent NHibernate - я начал собственный (теперь уже удаленный) маппер с атрибутами, а затем перешел на файлы на основе XML.
Тема "POCO мне ничего не дает" в основном проистекает из того, что сущности просто не являются нормальными объектами. У них много дополнительных функций, а также ограничений (таких как скорость запросов и т. Д.), О которых пользователь должен знать в любом случае. ORM, несмотря на LINQ, в любом случае не подлежат замене - заметьте, если вы начнете использовать их действительно интересные более высокие функции. Таким образом, в конце вы получаете POCO и все еще отстой с базовым классом и различной семантикой слева и справа.
Я считаю, что большинство сторонников POCO (как в: "должен иметь", а не "было бы неплохо") обычно НЕ продумали свои аргументы до реального конца. Вы получаете все виды довольно дурацких мыслей, почти на уровне «хранимых процедур быстрее, чем динамический SQL» - вещи, которые просто не соответствуют действительности. Вещи как:
- «Я хочу иметь их в тех случаях, когда они не нуждаются в сохранении базы данных» (использовать отдельный пул объектов, никогда не фиксировать),
- "Я могу захотеть иметь свою собственную функциональность в базовом классе (ORM должен разрешать классифицировать абстрактную сущность без функциональности, поэтому поместите свой СОБСТВЕННЫЙ базовый класс ниже, чем у ORM)
- «Я, возможно, захочу заменить ORM на другой» (поэтому никогда не используйте более высокую функциональность, надеюсь, что API ORM совместим, и тогда вам, ВСЕГДА, придется переписывать большие части).
В целом, сотрудники POCO также упускают из виду огромный объем работы, который на самом деле состоит в том, чтобы сделать его ПРАВИЛЬНЫМ - с такими вещами, как обновления транзакционных объектов и т. Д., В базовом классе содержится ТОННА кода. Некоторые из интерфейсов .NET ужасно реализовать на уровне POCO, хотя намного проще, если вы можете связать их с ORM.
Займите пост Томаса Яскулы здесь:
POCO это все о слабой связи и
проверяемость.
Это предполагает, что вы можете протестировать привязку данных, не имея ее? Тестируемость - это фиктивный фреймворк, и есть ДЕЙСТВИТЕЛЬНО мощные, которые могут даже «перенаправлять» вызовы методов.
Так что, когда вы делаете POCO, вы можете
проверить модель вашего домена (если вы
делаю DDD например) в изоляции.
Вам не нужно беспокоиться о том, как это
сохраняется Вам не нужно заглушки
контексты / сеансы для проверки вашего домена.
На самом деле не соответствует действительности. Постоянство должно быть частью любого теста модели домена, так как модель домена должна сохраняться. Вы всегда можете протестировать непостоянные сценарии, просто не фиксируя изменения, но многие тесты будут включать в себя сохранение и провал этого (например, счета с недействительными / отсутствующими данными недействительны, например, для записи на диск).
Еще одним преимуществом является то, что есть
менее протекающие абстракции. Так как
проблемы настойчивости не подталкивают к
доменный слой. Таким образом, вы применяете
Принцип SRP.
На самом деле нет. Надлежащая модель предметной области никогда не будет иметь постоянных методов в сущностях. Это дерьмовый ORM для начала (user.Save ()). OTOH базовый класс будет обрабатывать такие вещи, как проверка (IDataErrorInfo), обрабатывать события обновления свойств для постоянных файлов и в целом сэкономит вам массу времени.
Как я уже говорил, некоторые функции, которые вы ДОЛЖНЫ иметь, действительно трудно реализовать с помощью переменных в качестве хранилища данных - например, возможность перевести объект в режим обновления, внести некоторые изменения, а затем откатить их. Не нужно - сообщите Microsoft, которые используют это, если они доступны в их сетках данных (вы можете изменить некоторые свойства, а затем нажать escape, чтобы откатить изменения).
Третье преимущество, которое я вижу, это то, что
делая POCO, ваша модель домена более
эволюционный и гибкий. Можете добавить
новые функции проще, чем если бы
в сочетании с упорством.
Non-аргумент. Вы не можете поиграть в добавление полей в класс перистета без обработки персистентности, и вы можете добавить непостоянные объекты (методы) к классу, не относящемуся к poco, так же, как к классу poco.
В общем, мой базовый класс, не относящийся к POCO, сделал следующее:
- Обработка обновлений свойств и IDataErrorInfo - без написания пользователем строки кода для полей и элементов, которые может обрабатывать ORM.
- Обработка информации о состоянии объекта (новая, обновленная и т. Д.). Это внутренняя информация ИМХО, которая также довольно часто передается в пользовательский интерфейс. Обратите внимание, что это не метод сохранения, а просто свойство EntityStatus.
И он содержал ряд переопределяемых методов, которые объект мог бы использовать для расширения поведения БЕЗ реализации (публичного) интерфейса - так что методы были действительно частными для объекта. У него также было несколько внутренних свойств, таких как получение доступа к «диспетчеру объектов», ответственному за сущность, что также было точкой для запроса других сущностей (отправки запросов), что иногда было необходимо.