Modello dell'unità di lavoro

DBContext ti fornisce solo uno schema UoW se codifichi tutte le modifiche in una volta sola, il che non è affatto diverso dalla scrittura di una singola query in SQL tu stesso.

Dovresti utilizzare lo schema UoW se le tue prestazioni sono la tua preoccupazione: scrivere un singolo hit sul DB è meglio che scrivere 1 hit per cambiamento. Tuttavia, molte persone usano un ORM per la facilità d'uso degli strumenti RAD, non le prestazioni. Se è questo ciò su cui si focalizza la tua soluzione, allora dimentica UoW. Se hai bisogno di prestazioni, dovresti prendere in considerazione la possibilità di far ruotare il tuo pattern UoW usando comunque l'SQL diretto.

Ho attraversato questo ciclo negli ultimi anni, Unit of Work, avvolgendo il framework Entity di tutte le call del call center.

Finisci con un sacco di classi di repository inutili (con interfaccia associata), probabilmente avvolgendo una classe di repository di base generica con una Unit Of Work in cima che ha molte proprietà che espongono il repository.

E sì, sei corretto, Entity Framework È essenzialmente un'unità di lavoro con repository.

Ora sono al punto in cui non lo farò più per il mio prossimo progetto "da zero" e guarderò qualcosa di più simile a questo da Jimmy Bogard . (Sta usando una sessione di NHibernate, ma potrebbe ugualmente essere sostituito da EF)

Ma che ne è di mocking del DBContext per i test unitari? Questo può ancora essere ottenuto creando un Fake DBContext .

Si prega di notare. questa non è una raccomandazione in quanto tale, ma solo il mio attuale modo di pensare, e sono felice di sapere di eventuali problemi che questo approccio potrebbe avere.

Non tutti noi abbiamo il lusso di usare un framework che fornisce un componente incorporato "Unità di lavoro".

Se stai utilizzando DbContext di Entity Framework e ti è utile, usalo. In caso contrario, potresti dover implementare la tua "Unità di lavoro" da solo.

In effetti ho spostato Entity Framework DbContext e DbSet nelle mie classi generiche che seguono l'unità di lavoro. Il motivo principale per farlo è il test dell'unità.

Ho ottenuto le mie interfacce IUnitOfWork e IRepository che in realtà hanno due implementazioni.

Il primo è EFUnitOfWork che include DbContext e IRepository per DbSet . Questo viene iniettato nel codice di produzione ogni volta che aspetto un UnitOfWork.

Il secondo è un sostituto di IUnitOfWork (io uso NSubstitute per fare mock) e il mio ListBasedInMemoryRepository che, come suggerisce il nome, memorizza invece i dati in una lista del database.

Questa implementazione è utilizzata nei test unitari ogni volta che voglio testare il codice che normalmente userebbe Entity Framework. Quindi i miei test sono ora indipendenti dalla vera connessione al database come dovrebbero.