Repository Mønster: hvordan Lazy Load? eller, skal jeg dele dette Aggregate?

stemmer
66

Jeg har et domene modell som har konseptet med en redaktør og en Project.

En Editor eier en rekke prosjekter, og prosjektet har ikke bare redaktør eier, men også en rekke Editor medlemmer. Derfor har en redaktør også en rekke sluttet Prosjekter.

Jeg tar en DDD tilnærming til modellering dette og bruke Repository mønster for utholdenhet. Men jeg ikke Grok mønsteret godt nok ennå til å finne ut hvordan jeg skulle gjøre dette.

Jeg jobber på en forutsetning om at redaktør og prosjektleder er potensielt i samme aggregat, med roten blir Editor. Jeg kan derfor få en redaktør og deretter oppsummere sine prosjekter, og kunne derfra nummerere prosjektenes medlems Editors.

Men hvis jeg bare lov til å hente Redaktører fra min depotet, ikke det at jeg må laste alle prosjekter fra depotet når jeg får Editor som eier dem? Og hvis jeg ønsker å late last medlems Redaktører, må prosjektet en referanse til depotet i tillegg?

Alternativt, hvis jeg dele samlet og ha en redaktør depot og et prosjekt depot, hvordan skal jeg håndtere en transaksjon over to, for eksempel når et nytt prosjekt er lagt til en redaktør? For eksempel:

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

Er jeg misforstår hensikten med Repository mønster?

Publisert på 19/01/2009 klokken 14:10
bruker
På andre språk...                            


4 svar

stemmer
3

Det avhenger av programmets behov. Hvis det er et stort problem å laste alle prosjekter for en gitt Editor, og deretter prøve en lat lasting mønster som en virtuell Proxy .

Angå dovent lasting medlems Redaktører av et prosjekt, hvis du bruker Virtual Proxy, ser jeg ikke noe problem å injisere proxy med EditorRepository siden jeg ikke anser fullmakt til å være en del av domenet.

Hvis du splitter opp Aggregate, kan du undersøke Unit of Work mønster som en løsning på atomicity. Dette problemet, er imidlertid ikke unikt for DDD, og jeg er sikker på at det finnes andre løsninger for transaksjons atferd.

Svarte 23/01/2009 kl. 00:45
kilden bruker

stemmer
4

Hva med å dele ansvar i en EditorOwner og en EditorMember?

Uten å vite ditt domene, vil jeg tro at de ville ha ulike ansvarsområder - for eksempel kan EditorOwner være ganske rik (og kan være samlet root), men prosjektet kan kun trenger å vite en begrenset mengde om sine medlemmer, så den EditorMember objekt kan være ganske lett.

Disse domene objektene kan også forholde seg til brukere, men det ville være i en annen sammenheng.

Betyr det hjelpe ting, eller bare gjøre det mer komplisert?

Svarte 23/01/2009 kl. 02:55
kilden bruker

stemmer
0

Her har du 2 forskjellige relasjoner, en for eierskap og en for medlemskap.

Eierskapet forhold er en enkel en til mange (en eier for hvert prosjekt). Medlemskapet forhold er mange til mange (mange redaktører av prosjektet, mange prosjekter ved redaktør).

Du kan gi en eier eiendom på Prosjekt klasse, og gir en metode på ProjectRepository å få alle prosjekter som eies av en bestemt Editor.

For mange forhold, gir en medlemmer eiendom på Prosjekt klassen, og en metode på ProjectRepository å få alle prosjekter som inneholder spesifisert Editor som medlem.

Det synes også at redaktører og prosjekter er enheter, ville jeg sannsynligvis dele samlet, men kanskje disse begrepene har en bestemt mening i sammenheng som gjør det subentities av et aggregat.

Svarte 11/02/2009 kl. 11:01
kilden bruker

stemmer
30

Er jeg misforstår hensikten med Repository mønster?

Jeg kommer til å si "ja", men vet at jeg og hver person jeg har jobbet med har bedt det samme av samme grunn ... "Du tenker ikke fjerde dimensjonalt, Marty".

La oss forenkle det litt og feste med konstruktører istedenfor Lag metoder først:

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

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

Under, er prosjektet depot alltid lagre en gyldig eier ( p.EditorId) inn i prosjektet data som det er opprettet, og hvordan du re-fylle en redaktørens prosjekter, vil det være der. Det er derfor det er en god praksis å legge alle nødvendige egenskaper til konstruktører. Hvis du ikke ønsker å passere hele objektet, bare e.Idvil gjøre.

Og hvis jeg ønsker å late last medlems Redaktører, må prosjektet en referanse til depotet i tillegg?

Nå, om hvordan å re-fylle en redaktørens prosjekter on demand, har du et par valg avhengig av hva du går for. Rett Repository sier at du ønsker:

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

Men hvor du skal plassere den? Ikke inne Project, eller redaktør, du har rett, eller de vil ha for å få tilgang til repositories og det er ikke bra. Den ovennevnte Biten er løst koplet, men er ikke gjenbrukbare på egen hånd. Du har nettopp nådd grensene for Repository mønster.

Neste opp er en adapter lag av søknaden, med en felles kilde til repositories ( StaticServiceWrapper) og enten en slags EditorAdapter objekt (eller Aggregate eller hva du vil kalle dem), eller nå kan du blande i skjøtemetoder som kan snakke med noen og alle nødvendige repositories flytende. Jeg har ikke gjort det akkurat på denne måten i et produksjonssystem, men å vise deg en kortfattet eksempel:

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);
    }
}

I utgangspunktet, når din GetAll, GetById, legge til, oppdatere Fjern Object Repository er gjort, har du til å forlate foreninger alene og gå videre opp objektet / lag hierarki til de morsomme delene som Adaptere og Caches og forretningslogikk ( "Oh , min!" ).

Svarte 14/05/2009 kl. 02:40
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more