Это несколько похоже на этот вопрос, но более широко.
В целом, если ORM, такие как EF 4.1, поддерживают POCO, имеет ли смысл теперь, чтобы ваши доменные объекты были объектами, которые сохраняются в вашей базе данных?
В более старых ORM, таких как EF 4 или Linq-to-SQL, ваши «объекты базы данных» генерировались автоматически и были тесно связаны с вашей базой данных, поэтому для нетривиальных приложений они отображались в более надежные интеллектуальные доменные объекты до того, как положить на работу.
Идея с более новыми ORM состоит в том, чтобы просто создать надежные доменные сущности, а затем иметь уровень данных, который просто обеспечивает отображение между упомянутыми доменными сущностями и вашей СУБД?
Когда я пишу, у меня возникает ощущение, что это всегда было целью, но с трудом (легко) это возможно с помощью доступных инструментов, по крайней мере, в мире .NET.
источник
Ответы:
Я думаю, что общая цель ORM состоит в том, чтобы база данных отображалась непосредственно в доменные объекты, которые в идеале являются POCO. Так что ответ на ваш вопрос - да. Теперь, когда EF способен отображать POCO, идеально рассматривать эти POCO как доменные объекты. Для других ORM, таких как NHibernate, это было возможно некоторое время, и я считаю, что люди обычно используют их как таковые.
Но эта цель, состоящая в том, чтобы доменные объекты напрямую отображались в базу данных, не всегда достижима. В некоторых случаях требуется существенный перевод между базой данных и моделью предметной области. ORM может быть не в состоянии выполнить перевод. В этом случае вам может потребоваться слой промежуточных POCO, которые сопоставляются с ORM в базу данных, а затем слой перевода, который преобразует их в POCO домена и обратно.
источник