33 messaggi dal 10 maggio 2015
Ciao a tutti,
avrei da porre una domanda sull'utilizzo del design pattern Unit of Work.

Premetto di essere alle primissime armi con Entity Framework. Dopo essermi documentato un po' in giro, ho trovato che e' possibile creare un data layer generico per EF utilizzando il pattern Repository; fin qui tutto ok, mi e' chiaro il suo utilizzo.

Successivamente mi sono imbattuto appunto nel pattern Unit of Work e, da quello che ho potuto capire (ma sono tutt'altro che sicuro di questo), questo pattern serve a centralizzare le operazioni di persistenza sulle varie entita' dopo che queste sono state modificate per inserimento, modifica o cancellazione.

Ammesso che la mia interpretazione circa l'utilita' di UoW sia corretta (chiedo a voi), in quali casi e' consigliabile usare questo pattern e in quali casi, invece, se ne puo' fare a meno?

Ringrazio in anticipo per le risposte.
Buona giornata.
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,
usare il pattern Unit of Work è indicato quando devi persistere varie entità con un'unica operazione atomica, indivisibile.
Pensa per esempio alla vendita di un prodotto: potresti aver bisogno di salvare un Ordine, creare una Fattura e aggiungere una riga di Scarico dal magazzino.
Per minimizzare la probabilità che si verifichi un problema durante l'inserimento di una di quelle tre entità, che ti lascerebbe il db in uno stato inconsistente, si preferisce inviare i comandi tutti insieme, nel contesto di una transazione.
Con il pattern Unit of Work, riferito ad un ORM come Entity Framework, hai l'opportunità - appunto - di persistere le tre entità tutte insieme.

Entity Framework implementa sia già il pattern repository (vedi il DbSet<T>, con i suoi metodi Add, Create, Remove e sia il pattern Unit of Work, grazie al DbContext, che si occupa di persistere i cambiamenti tutti insieme solo quando invochi il suo metodo SaveChanges.

Quindi, se usi Entity Framework, stai già usando entrambi i pattern.

Alcuni sviluppatori, in certe situazioni, fanno un passo in più e creano una propria implementazione del pattern repository e del pattern unit of work e la usano per astrarre dal DbSet e dal DbContext.
Questo è utile se hai la necessità di schermare la logica di business della tua applicazione dalla tecnologia di persistenza. In qualche caso infatti può capitare che non tutti i dati possano essere recuperati con Entity Framework. Alcune entità potrebbero arrivati da un webservice, altre da un file di testo, e così via. Se hai fonti di dati eterogenee, allora secondo me ha senso creare una propria implementazione di Repository (ed eventualmente Unit of Work) per offrire alla tua applicazione un'interfaccia uniforme di accesso ai dati.

Negli altri casi, quando hai un solo database, mettersi a reimplementare i due pattern *potrebbe* essere ridondante e rappresentare una violazione del principio KISS.

Non ci sono regole valide in ogni caso, devi saper decidere tu, nella tua situazione, se un pattern rappresenta una buona scelta architetturale oppure se se ne può fare a meno perché non aggiunge abbastanza valore.

ciao,
Moreno

Enjoy learning and just keep making
33 messaggi dal 10 maggio 2015
Chiarissimo, grazie mille per le delucidazioni.
Buona giornata.

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.