Чи замінюють ORM POCO місця домену?

Це дещо схоже на це питання, але більш широке.

Взагалі, для таких ORM, як EF 4.1, що підтримують POCO, чи має сенс, щоб ваші доменні об'єкти були об'єктами, які зберігаються у вашій базі даних?

За старих ORM, таких як EF 4 або Linq-до-SQL, ваші "об'єкти баз даних" були автоматично сформовані та щільно з'єднані з вашою базою даних, і тому для нетривіальних додатків перед створенням їх було зображено на більш надійні, інтелектуальні об'єкти домену поставити на роботу.

Чи є ідея з новими ORM просто створити надійні доменні об'єкти, а потім мати рівень даних, який просто забезпечує відображення між зазначеними об'єктами домену та вашими СУБД?

Написавши, я відчуваю, що це завжди було метою, але це не легко (легко) можливо за допомогою доступних інструментів, принаймні, не у світі .NET.

Я думаю, що загальною метою ORM є те, що база даних відображається безпосередньо на об'єкти домену, які в ідеалі є POCO. Тож відповідь на ваше запитання - так. Тепер, коли EF здатний відображати POCO, ідеально розглядати ці POCO як доменні сутності. Для інших ОРМ, таких як NHibernate, це можливо вже деякий час, і я вважаю, що люди зазвичай використовують їх як такі.

Але ця мета - безпосередньо об’єкти домену безпосередньо відображені в базі даних, не завжди досяжна. Є деякі випадки, коли між базою даних та доменною моделлю необхідний значний переклад. ORM, можливо, не може зробити переклад. У цьому випадку ви можете захотіти шар проміжних POCO, які відображаються з ORM в базу даних, а потім шар перекладу, який змінює їх у доменні POCO і назад.