I POCO ORM sostituiscono le entità di dominio?

Questo è in qualche modo simile a questa domanda ma più ampio.

In generale, con ORM come EF 4.1 che supportano i POCO, ha ora senso che le entità del tuo dominio siano gli oggetti che persistono nel tuo database?

Con ORM precedenti come EF 4 o Linq-to-SQL, i tuoi "oggetti database" sono stati generati automaticamente e strettamente accoppiati al tuo database, quindi, per applicazioni non banali, sono stati mappati su entità di dominio più robuste e intelligenti prima di essere mettersi al lavoro.

L'idea con ORM più recenti è quella di creare entità di dominio robuste e quindi disporre di un livello dati che fornisca semplicemente una mappatura tra tali entità di dominio e il tuo DBMS?

Nello scrivere che ho la sensazione che questo sia sempre stato l'obiettivo, ma non facilmente (facilmente) possibile con gli strumenti disponibili, almeno non nel mondo .NET.

Penso che l'obiettivo generale con gli ORM sia che il database sia mappato direttamente su oggetti di dominio, che sono idealmente POCO. Quindi la risposta alla tua domanda è sì. Ora che EF è in grado di mappare i POCO, è ideale considerare quei POCO come entità di dominio. Per altri ORM come NHibernate questo è stato possibile per un po 'e credo che le persone li abbiano generalmente usati come tali.

Ma questo obiettivo di avere le entità di dominio direttamente mappate al database non è sempre raggiungibile. Ci sono alcuni casi in cui è necessaria una traduzione significativa tra il database e il modello di dominio. L'ORM potrebbe non essere in grado di eseguire la traduzione. In questo caso è possibile che si desideri uno strato di POCO intermedi mappati con l'ORM al database e quindi un livello di traduzione che li cambi in POCO di dominio e viceversa.