Devo disporre di unità di lavoro separate per ogni contesto limitato EF?

Question

Devo disporre di unità di lavoro separate per ogni contesto limitato EF?

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

4

Ho alcuni contesti limitati EF come segue

public class BoundedContext_1 : DbContext
{
    IDbSet<A> As { get; set; }
    IDbSet<B> Bs { get; set; }
}

public class BoundedContext_2 : DbContext
{
    IDbSet<C> Cs { get; set; }
    IDbSet<D> Ds { get; set; }
}

public class BoundedContext_3 : DbContext
{
    IDbSet<D> Ds { get; set; }
    IDbSet<E> Es { get; set; }
    IDbSet<F> Fs { get; set; }
}

Sto cercando di implementare il modello UoW / Repository per la mia soluzione.

Ora mi sembra che finirò per creare molti repositori (7 in questo caso) ognuno dei quali dedicato a un IDbSet separato di un contesto limitato e quindi con molte unità di lavoro (3 in questo caso) che hanno i propri repository - questo è un grande sforzo e non sembra fattibile dal momento che il mio modello attuale è molto più complicato rispetto all'esempio sopra.

La domanda è "Sono obbligato ad andare in quel modo? dovrei avere un UoW separato per ogni contesto limitato con i propri repository?" O c'è un modo per evitarlo e farlo in un modo più semplice?

Grazie in anticipo

repository unit-of-work

posta Kamran 13.10.2014 - 18:47

fonte

2 risposte

Leggi altre domande sui tag repository unit-of-work

Come aggiungo funzionalità di ottimizzazione del tempo di collegamento al mio compilatore basato su LLVM? Esecuzione differita di Dispose per oggetti IDisposable

score 1 · Answer 1

No, non sei obbligato ad andare in quel modo. In effetti, puoi usare DbContexts e IDbSet proprio come sono.

Un DbContext è un'implementazione dell'unità di modello di lavoro. Una volta creato, aggregherà tutte le modifiche apportate alle sue entità e si impegnerà quando richiesto.

Allo stesso modo, un IDbSet è un'implementazione del modello di repository. Serve come una raccolta astratta di entità (IQueryable), che può essere interrogata e ha operazioni CRUD di base.

Ecco alcuni esempi:

public class BService
{
    public void DoSomethingToB(Guid bId)
    {
        using (var unitOfWork = new BoundedContext_1())
        {
            var BRepository = unitOfWork.Bs;
            var b = BRepository.Find(bId);
            b.DoSomething();
            unitOfWork.SaveChanges();
        }
    }

    public B AddNewB()
    {
        var newB = new B();
        using (var unitOfWork = new BoundedContext_1())
        {
            var BRepository = unitOfWork.Bs;
            BRepository.Add(newB);
            unitOfWork.SaveChanges();
        }
        return newB;
    }
}

Questo sicuramente funzionerà. Non è stata creata una singola classe.

La domanda è se l'implementazione EF è sufficiente. Dovresti verificare se i requisiti del tuo progetto richiedono un livello di astrazione attorno all'implementazione di EF.

Tali ragioni potrebbero essere:

Hai qualche logica non generica in un repository o un'unità di lavoro che vuoi testare unitamente. Non è semplice per l'EF di test unitario, quindi potresti considerare di chiamare EF dal tuo repository / uow e prenderlo in giro durante il test dell'unità.
Vuoi un'API esplicita per i tuoi repository. per esempio. BRepository.AddNewB (newB) anziché BRepository.Add (newB) o bRepo.GetBWithId (bId) anziché bRepo.Find (bId).
Si stima che sarà necessario sostituire il DAL un giorno e supportare una tecnologia diversa da EF. Ho sentito molto, ma non ho mai visto una tale sostituzione nella pratica. Di solito quando un progetto cambia il suo DAL, la nuova tecnologia è significativamente diversa e l'API viene modificata insieme all'implementazione (ad esempio passando da un RDBS a un DB NoSQL).

score 1 · Answer 2

La semplice risposta alla tua domanda è che EF è di per sé un'implementazione del pattern UoW / Repository. Il fatto che tu stia cercando di implementare un pattern Uow / Repository come se EF fosse la tua fonte di dati è una buona indicazione che stai pensando al tuo problema in modo errato.

Or there is a way to avoid this and do it in a simpler way?

Sì. È sufficiente utilizzare EF come implementazione UoW / Repo o EF scrap per un'implementazione alternativa.