Les ORM POCO remplacent-ils les entités de domaine?

Ceci est quelque peu similaire à cette question mais plus large.

En général, avec des ORM comme EF 4.1 prenant en charge les POCO, est-il maintenant logique que vos entités de domaine soient les objets qui sont conservés dans votre base de données?

Avec des ORM plus anciens comme EF 4 ou Linq-to-SQL, vos "objets de base de données" étaient générés automatiquement et étroitement couplés à votre base de données, et donc, pour les applications non triviales, étaient mappés à des entités de domaine intelligentes plus robustes avant d'être mettre au travail.

L'idée avec les nouveaux ORM est-elle de simplement construire des entités de domaine robustes, puis d'avoir une couche de données qui fournit simplement un mappage entre lesdites entités de domaine et votre SGBD?

Par écrit, j'ai l'impression que cela a toujours été le but, mais pas facilement (facilement) possible avec les outils disponibles, du moins pas dans le monde .NET.

Je pense que l'objectif général des ORM est que la base de données est directement mappée aux objets de domaine, qui sont idéalement des POCO. La réponse à votre question est donc oui. Maintenant que EF est capable de mapper avec des POCO, il est idéal de considérer ces POCO comme des entités de domaine. Pour d'autres ORM comme NHibernate, cela est possible depuis un certain temps et je pense que les gens les utilisent généralement comme tels.

Mais cet objectif d'avoir des entités de domaine directement mappées à la base de données n'est pas toujours réalisable. Dans certains cas, une traduction importante est nécessaire entre la base de données et le modèle de domaine. L'ORM peut ne pas être capable de faire la traduction. Dans ce cas, vous souhaiterez peut-être une couche de POCO intermédiaires qui sont mappés avec l'ORM à la base de données, puis une couche de traduction qui les transforme en POCO de domaine et vice-versa.