Pattern Repository: come Lazy Load? o, dovrei dividere questo aggregato?

Question

Pattern Repository: come Lazy Load? o, dovrei dividere questo aggregato?

voti

66

Ho un modello di dominio che ha il concetto di un editor e un progetto.

Un Editor possiede una serie di progetti, e un progetto non ha solo un proprietario Editor, ma anche un numero di membri Editor. Pertanto, un Editor ha anche un certo numero di progetti uniti.

Sto prendendo un approccio DDD per modellare questo e utilizzando il modello Repository per la persistenza. Tuttavia, non mi Grok il modello abbastanza bene ancora determinare come devo fare questo.

Sto lavorando sul presupposto che Editor e Project sono potenzialmente nello stesso aggregato, con la radice essendo Editor. Posso quindi ottenere un Editor e quindi enumerare i suoi progetti, e da lì poteva enumerare editori membri dei progetti.

Tuttavia, se mi è permesso solo di recuperare i redattori dal mio repository, questo non significa che devo caricare tutti i Progetti dal repository quando ricevo l'editor che li possiede? E se voglio carico pigri Editors membri, il progetto ha bisogno di un riferimento al repository come bene?

In alternativa, se dividere l'aggregato ed avere un repository Editor e un repository di progetto, come devo gestire una transazione tra le due, come ad esempio quando si aggiunge un nuovo progetto per un Editor? Per esempio:

Editor e = new Editor(Editor Name);
editorRepository.Add(e);

Project p = e.CreateProject(Project Name);
projectRepository.Add(p);    // These two lines
editorRepository.Save(e);    // should be atomic

Sto interpretando male l'intento del Pattern Repository?

domain-driven-design repository-pattern lazy-loading aggregate ddd-repositories

È pubblicato 19/01/2009 alle 15:10
dall'utente Giraffe

In altre lingue...

4 risposte

voti

3

Dipende dalle esigenze dell'applicazione. Se si tratta di un grosso problema per caricare tutti i progetti per un dato Editor, quindi provare un modello lazy loading come un proxy virtuale .

Per quanto riguarda il caricamento pigramente i redattori membro di un progetto, se si utilizza Virtual Proxy, non vedo un problema iniettando il proxy con l'EditorRepository dato che non considero il proxy per far parte del dominio.

Se si divide l'aggregato, è possibile indagare l'unità di lavoro modello come una soluzione per atomicità. Questo problema, però, non riguardano solo DDD e sono sicuro che ci sono altre soluzioni per comportamento transazionale.

Risposto il 23/01/2009 a 01:45
fonte dall'utente moffdub

voti

4

Che ne dite di suddivisione delle responsabilità in un EditorOwner ed un EditorMember?

Senza conoscere il vostro dominio, mi piacerebbe immaginare che avrebbero avuto diverse responsabilità - per esempio, l'EditorOwner potrebbe essere piuttosto ricca (e potrebbe essere la radice di aggregazione), ma il progetto può solo bisogno di sapere una quantità limitata sui suoi membri, in modo da l'oggetto EditorMember può essere molto leggero.

Questi oggetti di dominio possono riguardare anche gli utenti, ma che sarebbe in un altro contesto.

Fa che aiutare le cose, o semplicemente rendono più complicato?

Risposto il 23/01/2009 a 03:55
fonte dall'utente Michael Hart

voti

0

Qui si hanno 2 rapporti diversi, uno per la proprietà e uno per l'adesione.

Il rapporto di proprietà è un semplice uno a molti (un proprietario per ogni progetto). La relazione iscrizione è molti a molti (molti editor di progetto, molti progetti di editore).

Si potrebbe fornire una proprietà Proprietario sulla classe del progetto, e fornire un metodo sul ProjectRepository per ottenere tutti i progetti di proprietà di un editor specifico.

Per i molti rapporti, fornire una proprietà Membri sulla classe del progetto, e un metodo sul ProjectRepository per ottenere tutti i progetti che contengono Editor specificato come membro.

Sembra, inoltre, che i redattori e Progetti sono entità, probabilmente dividere l'aggregato, ma forse questi termini hanno un significato specifico nel contesto che lo rendono sottoentità di un aggregato.

Risposto il 11/02/2009 a 12:01
fonte dall'utente thinkbeforecoding

ifatree · Accepted Answer · 2009-05-14 03:40

Sto interpretando male l'intento del Pattern Repository?

Sto per dire "sì", ma so che io e tutte le persone con cui ho lavorato ha chiesto la stessa cosa per lo stesso motivo ... "Non sei pensare quarto dimensionalmente, Marty".

Facciamo semplificare un po 'e bastone con i costruttori, invece di creare dei metodi prima:

Editor e = new Editor("Editor Name");
e = editorRepository.Add(e);

Project p = new Project("Project Name", e);
p = projectRepository.Add(p);

Sotto, il repository del progetto è sempre la memorizzazione proprietario di un valido ( p.EditorId) nei dati di progetto, come è stato creato, e comunque si ripopolare i progetti di un editor, sarà lì. Questo è il motivo per cui si tratta di una buona pratica di mettere tutte le proprietà richieste in costruttori. Se non si desidera passare l'intero oggetto, solo la e.Idfarà.

E se voglio carico pigri Editors membri, il progetto ha bisogno di un riferimento al repository come bene?

Ora, quanto a come ripopolare i progetti di un editor su richiesta, si dispone di un paio di scelte a seconda di quello che stai per andare. Repository dritto dice che si desidera:

IEnumerable<Project> list = projectRepository.GetAllProjects()
                                .Where(x => x.editorId == e.Id);

Ma dove metterlo? Non all'interno del progetto, o Editor, hai ragione, o si dovrà ottenere l'accesso a repository e che non va bene. Il codice sopra è debolmente accoppiati, ma non è riutilizzabile per sé. Hai appena raggiunto i limiti di Pattern Repository.

Next up è uno strato adattatore per la vostra applicazione, con una fonte condivisa di repository ( StaticServiceWrapper) e sia una sorta di oggetto EditorAdapter (o aggregazione o qualsiasi altra cosa tu li chiameresti) oppure ora è possibile mescolare in metodi di estensione in grado di comunicare con ogni e tutti gli archivi necessari correntemente. Non ho fatto esattamente in questo modo in un sistema di produzione, ma per mostrare un esempio concisa:

public static class Aggregators
{
    // one to one, easy
    public static Editor GetOwner(this Project p)
    {
        return StaticServiceWrapper.editorRep.GetEditorById(p.editorId);
    }

    // one to many, medium
    public static IEnumerable<Project> GetProjects(this Editor e) 
    { 
        return StaticServiceWrapper.projectRep.GetAllProjects()
                .Where(x => x.editorId == e.Id);
    }

    // many to many, harder
    public static IEnumerable<Editor> GetMembers(this Project p)
    {
        var list = StaticServiceWrapper.projectMemberMap.GetAllMemberMaps()
                        .Where(x => x.projectId == p.projectId);

        foreach ( var item in list )
            yield return StaticServiceWrapper.editorRep.GetEditorById(item.editorId);
    }
}

In sostanza, una volta che il GetAll, GetById, Aggiungere, aggiornare, rimuovere oggetti Repository è fatto, hai avuto modo di lasciare in pace le associazioni e passare la gerarchia di oggetti / layer alle parti divertenti come adattatori e cache e Business Logic ( "Oh , la mia!" ).