Что 'большие' преимущества состоят в том, чтобы иметь Постепенно с ORM?

Нет. Точка. Все преимущества, которые люди любят разбрасывать, - это преимущества, которые не важны в большом масштабе картины. Я предпочитаю сильный базовый класс для объектов сущностей, который на самом деле содержит много интегрированного кода (например, генерирование событий изменения свойств при изменении свойств), чем писать все это самостоятельно. Обратите внимание, что я ДЕЙСТВИТЕЛЬНО написал (в то время коммерчески доступный) ORM для .NET до того, как появились «LINQ» или «ObjectSpaces». Я использовал O / R mappers вот уже 15 лет и никогда не встречал случая, когда POCO действительно стоил бы возможных проблем.

При этом атрибуты МОГУТ быть плохими по другим причинам.В наши дни я предпочитаю подход Fluent NHibernate - запустил свой собственный (ныне вышедший на пенсию) маппер с атрибутами, а затем перешел на файлы на основе XML.

Тема «POCO ничего мне не дает» в основном исходит из того, что сущности - это ПРОСТО НЕ ОБЫЧНЫЕ ОБЪЕКТЫ. У них есть множество дополнительных функций, а также ограничения (например, скорость запроса и т. Д.), О которых пользователь должен знать в любом случае. ORM, несмотря на LINQ, в любом случае нельзя заменить - нет, если вы начнете использовать их действительно интересные более высокие функции. Итак, в конце вы получаете POCO и по-прежнему отстой с базовым классом и разной семантикой слева и справа.

Я считаю, что большинство сторонников POCO (например, «должно быть», а не «было бы хорошо») обычно НЕ продумывали свои аргументы до конца. У вас возникают всевозможные довольно дрянные мысли, в значительной степени на уровне «хранимые процедуры быстрее динамического SQL» - вещи, которые просто не соответствуют действительности. Такие вещи, как:

• «Я хочу иметь их в тех случаях, когда они не нуждаются в сохранении в базе данных» (используйте отдельный пул объектов, никогда не фиксируйте),
• «Я могу захотеть иметь свои собственные функции в базе класс (ORM должен включать абстрактные сущности, классифицированные без функциональности, поэтому поместите свой СОБСТВЕННЫЙ базовый класс ниже одного из ORM)
• «Я могу захотеть заменить ORM другим» (так что никогда не используйте какие-либо более высокие функциональные возможности, надеюсь, ORM API совместим, и тогда вам ВСЕГДА, возможно, придется переписывать большие части).

В целом люди, занимающиеся POCO, также упускают из виду огромный объем работы, который на самом деле состоит в том, чтобы сделать его ПРАВИЛЬНЫМ - с такими вещами, как обновления транзакционных объектов и т. Д., Есть ТОННА кода в базовом классе.Некоторые из интерфейсов .NET ужасно реализовать на уровне POCO, хотя намного проще, если вы можете привязаться к ORM.

Посмотрите здесь сообщение Томаса Яскулы:

POCO - все дело в слабой связи и тестируемости.

Это предполагает, что вы можете тестировать привязку данных, не имея ее? Тестируемость - это фиктивный фреймворк, и есть ДЕЙСТВИТЕЛЬНО мощные фреймворки, которые могут даже «перенаправлять» вызовы методов.

Итак, когда вы выполняете POCO, вы можете протестировать свою модель домена (например, если вы выполняете DDD) изолированно. Вам не о чем беспокоиться. о том, как это сохраняется. Вам не нужно заглушать контексты / сеансы для тестирования своего домена.

На самом деле неправда. Устойчивость должна быть частью любого теста модели предметной области, так как модель предметной области должна сохраняться. Вы всегда можете протестировать непостоянные сценарии, просто не фиксируя изменения, но многие тесты будут включать в себя постоянство и сбой (например, счета-фактуры с недопустимыми / отсутствующими данными не могут быть записаны на диск, например).

Еще одно преимущество - это меньше дырявых абстракций. Поскольку проблемы устойчивости не переносятся на уровень домена . Таким образом, вы применяете принцип SRP.

На самом деле нет. В правильной модели предметной области никогда не будет методов сохранения в объектах. Это дерьмовый ORM для начала (user.Save ()). OTOH базовый класс будет выполнять такие вещи, как проверка (IDataErrorInfo), обрабатывать события обновления свойств в постоянном поле и в целом экономить вам массу времени.

Как я уже говорил, некоторые функции, которые ДОЛЖНЫ иметься, действительно сложно реализовать с помощью переменных в качестве хранилища данных - например, возможность перевести объект в режим обновления, внести некоторые изменения и затем откатить их. Не требуется - сообщите об этом Microsoft, использующему это, если оно доступно в их сетках данных (вы можете изменить некоторые свойства, затем нажмите escape, чтобы откатить изменения).

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

Без аргументов. Вы не можете играть с добавлением полей в класс peristet без обработки персистентности, и вы можете добавлять непостоянные функции (методы) в класс, не являющийся poco, так же, как и в класс poco.

В общем, мой базовый класс, не относящийся к POCO, выполнял следующие действия:

• Обработка обновлений свойств и IDataErrorInfo - без написания пользователем строки кода для полей и элементов, которые ORM может обрабатывать.
• Обработка информации о состоянии объекта (новый, обновленный и т. Д.). Это внутренняя информация IMHO, которая также довольно часто передается в пользовательский интерфейс. Обратите внимание, что это не метод «сохранения», а просто свойство EntityStatus.

И он содержал ряд переопределяемых методов, которые объект мог использовать для расширения поведения БЕЗ реализации (общедоступного) интерфейса - так что методы были действительно частными для объекта. У него также были некоторые дополнительные внутренние свойства, такие как доступ к «диспетчеру объектов», отвечающему за сущность, который также был точкой для запроса других сущностей (отправка запросов), что иногда было необходимо.

Поддержка POCO в ORM заключается в разделении ответственности в соответствии с Принципом единой ответственности . Благодаря поддержке POCO ORM может напрямую взаимодействовать с моделью предметной области без необходимости "замутить" домен специфическим для доступа к данным кодом. Это гарантирует, что модель предметной области предназначена для решения только проблем, связанных с предметной областью, а не проблем доступа к данным.

Помимо этого, поддержка POCO может упростить тестирование поведения отдельных объектов без необходимости в базе данных, информации о сопоставлении или даже ссылках на сборки ORM. Возможность иметь «автономные» объекты может значительно упростить разработку, поскольку объекты легко создавать и предсказывать.

Кроме того, поскольку объекты POCO не привязаны к источнику данных, вы можете обращаться с ними одинаково, независимо от того, были ли они загружены из вашей первичной базы данных, альтернативной базы данных, плоского файла или любого другого процесса. Хотя это может показаться не сразу полезным, одинаковое отношение к вашим объектам независимо от источника может упростить прогнозирование поведения и работу с ним.

Я выбрал NHibernate для моей последней ORM из-за поддержки объектов POCO, с чем он очень хорошо справляется. Это соответствует подходу к проектированию, основанному на домене, которому следует проект, и обеспечивает отличное разделение между базой данных и доменом.

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

В NHibernate вам необходимо пометить все члены класса public или protected как виртуальные , чтобы включить поддержку отложенной загрузки. Это ограничение, хотя и не сильно изменило мой уровень домена, оказало влияние на его дизайн.