Entity Framework ed evitando il modello di dominio anemico

11

Nella nostra logica aziendale abbiamo occasionalmente metodi definiti in questo modo:

User.ResetCourse(Course courseToReset)

Il problema è che sia l'utente che il corso sono oggetti proxy Entity Framework. Ciò significa che quando colpiamo le proprietà di navigazione su Utente o Corso, può causare un enorme successo al database perché quegli oggetti non sono IQueryable e quindi li scorre normalmente.

Per risolvere questo problema abbiamo cambiato la firma in:

User.ResetCourse(MyDBContext db, Course courseToReset)

Ciò significa che possiamo interrogare direttamente il database per apportare le modifiche di cui abbiamo bisogno in modo efficiente, ma passare il contesto del database a un oggetto business sembra così sbagliato.

Successivamente abbiamo migrato all'utente un livello di servizio, il che significa che abbiamo qualcosa del tipo:

CourseService.ResetForUser(Course courseToReset, User forUser)

Questo servizio ha un riferimento al DBContext inserito nella creazione, ma ora i nostri oggetti business sono solo buste di dati senza comportamento (ovvero un modello di dominio anemico).

Come possiamo evitarlo?

c# entity-framework domain-model business-logic

— Steve
fonte

11

Un po 'di suoni come se avessi appena raggiunto la consapevolezza che i modelli di framework di entità sono in realtà DTO e non sono affatto un modello di dominio. Stai davvero provando a fare DDD? In caso contrario, probabilmente non importa.

— Sig. Cochese,

3

I servizi ADM plus sono una buona architettura per molte cose

— Ewan

1

Pertinente: ADM non è un anti-pattern, è un design SOLID .

— John Wu,

2

@JohnWu è un articolo molto distorto. In effetti contiene una versione "Strawman" di un modello di dominio avanzato, includendo il modello Record attivo nell'esempio avanzato. Certamente, Active Record non è sposato in DDD e in generale è una scelta sbagliata per qualsiasi applicazione complessa.

— RibaldEddie,

8

Il problema è che in primo luogo stai usando gli oggetti EF come oggetti di dominio. Gli oggetti EF sono modelli di dati NON modelli di business.

È necessario dichiarare gli oggetti business che offrono la libertà di fare ciò di cui si ha bisogno, quindi recuperarli e archiviarli con un repository. Il repository mapperà le entità EF alle entità aziendali. Gli oggetti EF non devono mai essere utilizzati al di fuori dei repository.

— TheCatWhisperer
fonte

0

Probabilmente puoi evitarlo facendo qualcosa del tipo:

CourseService.prepareForUserCourseReset(DBContext db);
User.reset();
Course.reset();
CourseService.completeUserCourseReset(DBContext db);

O qualcosa in tal senso, comunque, se catturi la mia deriva. Sembra che l'approccio che hai con il modo iniziale che hai descritto sia correlato alle prestazioni e non necessariamente alla struttura del dominio. Quindi davvero dovresti considerare di risolvere il problema delle prestazioni nel livello di servizio ma puoi mantenere il comportamento nel dominio. Sarebbe utile sapere cosa significa reimpostare l'utente / corso in questo contesto se si desidera una risposta migliore.

— RibaldEddie
fonte

-1

Tradizionalmente, questo viene risolto utilizzando una strategia di recupero per ogni caso d'uso che indica a Entity Framework di caricare con entusiasmo le associazioni necessarie sulla query iniziale utilizzando IQueryable.Include ().

Udi Dahan ha scritto un post che descrive l'approccio generale, che può essere adattato a Entity Framework.

http://udidahan.com/2007/09/16/fetching-strategy-nhibernate-implementation-available/

— pnschofield
fonte