I POCO ORM sostituiscono le entità di dominio?

9

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

In generale, con ORM come EF 4.1 che supporta POCOs, ha senso avere le entità di dominio essere gli oggetti che sono persistenti nel tuo database?

Con ORM più vecchi come EF 4 o Linq-to-SQL, i tuoi "oggetti del database" sono stati generati automaticamente e strettamente accoppiati al tuo database, e così, per applicazioni non banali, sono stati mappati su un dominio più robusto e intelligente entità prima di essere messa al lavoro.

L'idea con i nuovi ORM è sufficiente per creare solide entità di dominio e quindi disporre di un livello dati che fornisce semplicemente una mappatura tra dette entità di dominio e il tuo DBMS?

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

    
posta Adam Rackis 25.10.2011 - 19:25
fonte

1 risposta

8

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

Ma questo obiettivo di avere le entità di dominio direttamente mappate al database non è sempre possibile. Vi 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, potresti volere uno strato di POCO intermedio mappato con l'ORM al database e quindi un livello di traduzione che li modifichi in POCO di dominio e di nuovo indietro.

    
risposta data 25.10.2011 - 19:37
fonte