Какие "большие" преимущества имеют Poco с ORM?

Ответ 1

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

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

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

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

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

Надеюсь, что это поможет

Ответ 2

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

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

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

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

• "Я хочу иметь их в тех случаях, когда им не нужно сохранять базу данных" (используйте отдельный пул объектов, никогда не совершайте),
• "Я могу захотеть иметь свои собственные функциональные возможности в базовом классе (ORM должен allos абстрактной сущности, классифицированной без функциональности, поэтому поместите свой базовый класс OWN ниже одного из ORM)
• "Я могу заменить ORM на другой" (поэтому никогда не используйте более высокую функциональность, надейтесь, что ORM API совместим, а затем вам может потребоваться переписать большие части).

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

Возьмите пост Томаса Джаскулы здесь:

POCO - все о свободной связи и проверяемость.

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

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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