Unità di lavoro / modello di repository con consigli sull'iniezione dipendente

Question

Unità di lavoro / modello di repository con consigli sull'iniezione dipendente

#1 da (4 voti)
#2 da (2 voti)

2

Sto sviluppando una serie di classi di repository e una classe UnitOfWork (più ovviamente la sua interfaccia IUnitOfWork). Sto usando Castle Windsor, che inietta le dipendenze tramite i costruttori.

Il mio livello aziendale ha classi come "CustomerBusinessLogic", con metodi come RetrieveCustomer, SaveCustomer, ecc. Questi a loro volta usano UOW per eseguire le operazioni del database.

Non riesco a trovare come / dove la classe BLL dovrebbe ottenere un'istanza di UOW. Non sembra giusto iniettarlo nel ctr, come un'unità di lavoro è esattamente questo - un'unità di lavoro! Penso che un singolo metodo (LoadCustomer, SaveCustomer) dovrebbe essere responsabile per l'istanziazione dell'UOW per tutta la durata della sua operazione. Tuttavia, fare questo significa ricorrere a un localizzatore di servizi, che è un anti-pattern.

Suggerimenti benvenuti!

repository-pattern dependency-injection unit-of-work

posta Andrew Stephens 11.01.2013 - 21:51

fonte

2 risposte

Leggi altre domande sui tag repository-pattern dependency-injection unit-of-work

Come concedere in licenza il mio closed source e freeware (articoli per le donazioni) - usando le creative commons? Come vanno insieme queste tecnologie?

score 4 · Answer 1

Ho appena terminato un articolo oggi sul schema del repository (con implementazioni di esempio ).

La cosa con la maggior parte dei contenitori di ioc .NET è che supportano lo scoping. Cioè, possono creare oggetti con una durata limitata. Funziona molto bene con le applicazioni HTTP poiché l'ambito è lo stesso della durata di una richiesta HTTP.

Se utilizzi ASP.NET MVC puoi combinarlo con le funzionalità incorporate di MVC per attivare UoW se non sono stati rilevati errori: link

Se usi un qualsiasi altro tipo di applicazione, di solito creo un ambito da solo (ad esempio per racchiudere un comando):

using (var scope = MyContainer.CreateChildCointainer())
{
    using (var uow = scope.Resolve<IUnitOfWork>())
    {
        // do something here


        uow.SaveChanges();
    }
}

Il fatto è che i repository ecc non devono essere consapevoli dell'unità di lavoro (se si usano i database in .NET). L'implementazione UoW può garantire che tutte le implementazioni OR / M o UoW arrechino tutti i comandi db nella transazione.

score 2 · Answer 2

Quello che stai descrivendo è un modello molto comune in cui invece di iniettare l'oggetto di interesse vuoi iniettare un oggetto che può creare istanze dell'oggetto di interesse. Potresti chiamarlo fabbrica. Se stai utilizzando Autofac, viene infornato semplicemente iniettando Func<T> (per creare istanze di% codice%). Sono abbastanza sicuro che Castle Windsor abbia questa stessa caratteristica.

Potrebbe essere necessario considerare ulteriormente i confini della tua unità di lavoro. La tua domanda implica che un'unità di lavoro rientri nei limiti di, diciamo, T ma chiediti cosa succede se riusino quel metodo all'interno di un'unità di lavoro più ampia. Quali sono i limiti della tua unità di lavoro allora, e la tua strategia di iniezione e l'implementazione dell'unità di lavoro la gestiscono correttamente.