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