Repository minta: hogyan Lazy Load? vagy, kéne osztani ezt Összesített?

Question

Repository minta: hogyan Lazy Load? vagy, kéne osztani ezt Összesített?

szavazat

66

Van egy domain modell, amely a koncepció egy szerkesztő és egy projekt.

Egy szerkesztő tulajdonában több olyan projektek, és a projekt nem csak egy szerkesztő tulajdonos, hanem számos szerkesztő tagja. Ezért egy szerkesztő is számos „csatlakozott” projektek.

Szedek egy DDD megközelítése modellezés ezt, és a tároló mintát kitartás. Én azonban nem grokkolom a minta elég jól még nem határozza meg, hogyan kell ezt csinálni.

Dolgozom a feltételezés, hogy szerkesztő és projekt potenciálisan azonos összességében, a gyökér, hogy szerkesztő. Azt tehát, hogy egy szerkesztő, majd felsorolni e projektek, és ez onnan felsorolni azokat a projektek tag szerkesztők.

Azonban, ha én csak azt tették lehetővé, hogy letölteni Szerkesztők én adattár, nem ez jelenti azt, hogy betöltse az összes projekt a tárolóból, ha megkapom a szerkesztő, hogy birtokolja őket? És ha azt szeretnénk, hogy lusta terhelés a tag szerkesztők, a Project szüksége van egy hivatkozás a tároló is?

Egy másik változat szerint, ha jól szét az aggregált, és van egy szerkesztő adattár és Project adattár, hogyan érdemes kezelni a tranzakció mind a két, például amikor egy új projekt adunk egy szerkesztő? Például:

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

Én félreértelmezi a szándék a Repository minta?

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

A kérdést 19/01/2009 15:10
felhasználó Giraffe

Más nyelveken...

4 válasz

szavazat

3

Attól függ, hogy az alkalmazás igényeinek. Ha ez egy nagy probléma, hogy töltse be az összes projekt egy adott szerkesztő, majd próbálja meg egy lusta rakodási mintát, mint egy virtuális proxy .

Ami lustán betöltése tagja szerkesztők a projekt, ha használja Virtual Proxy, nem látok problémát befecskendezésével proxyt a EditorRepository óta nem tartom a proxy, hogy része legyen a domain.

Ha szét az összesített, akkor vizsgálja meg a munkaegység mintában egy megoldást atomicitás. Ez a probléma azonban nem egyedülálló a DDD és biztos vagyok benne, vannak más megoldások tranzakciós viselkedést.

Válaszolt 23/01/2009 01:45
a forrás felhasználó moffdub

szavazat

4

Mit szólnál felosztása feladatait egy EditorOwner és EditorMember?

Anélkül, hogy tudnánk a domain, gondolom hogy volna különböző feladatokat - például a EditorOwner lehet elég gazdag (és lehet aggregált gyökér), de a projekt csak akkor kell tudni korlátozott mennyiség mintegy tagjai, így a EditorMember tárgy lehet egészen világos.

Ezek a domain tárgyak is vonatkozhatnak felhasználók, de ez lenne más összefüggésben.

Segít ez a dolgok, vagy csak teszi a bonyolultabb?

Válaszolt 23/01/2009 03:55
a forrás felhasználó Michael Hart

szavazat

0

Itt van 2 különböző kapcsolatokat, egy tulajdon és egy tagsági.

A tulajdonosi kapcsolat egy egyszerű, egy sok (az egyik tulajdonos az egyes projektek). A tagsági viszony sok sok (sok Szerkesztők által projekt számos projekt által szerkesztő).

Lehet, hogy egy tulajdonos ingatlan a projekt osztály, valamint egy eljárás a ProjectRepository, hogy minden projekt tulajdonosa egy speciális szerkesztő.

A sok kapcsolat, hogy egy Tag tulajdonság a projekt osztály, valamint eljárás a ProjectRepository, hogy minden projekt, amely meghatározott szerkesztő tagjaként.

Úgy tűnik, hogy szerkesztők és projektek olyan entitások, azt valószínűleg szét az összesített, de talán ezek a kifejezések sajátos jelentése az összefüggésben, hogy teszik subentities aggregált.

Válaszolt 11/02/2009 12:01
a forrás felhasználó thinkbeforecoding

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

Én félreértelmezi a szándék a Repository minta?

Azt fogom mondani: „igen”, de tudom, hogy én és minden ember, akivel valaha dolgoztam kérte ugyanezt ugyanezen okból ... „Nem gondolkozol 4. dimenzióban, Marty”.

Nézzük egy kicsit egyszerűsíteni, és kibír konstruktőrök helyett létrehozása módszerek első:

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

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

Alatta, a projekt tárolójának mindig tárolására érvényes tulajdonosa ( p.EditorId) a projekt adatait, ahogy ott volt, és bárhogyan újra feltölti egy szerkesztői projektek, ott lesz. Ez az, amiért ez egy jó gyakorlat, hogy az összes szükséges tulajdonságokat konstruktőrök. Ha nem akarja átadni az egész tárgy, csak a e.Idfog tenni.

És ha azt szeretnénk, hogy lusta terhelés a tag szerkesztők, a Project szüksége van egy hivatkozás a tároló is?

Most, hogy hogyan kell újra feltölti egy szerkesztői projektek kereslet, van egy pár választás attól függően, hogy mit megy. Egyenes Repository mondja szeretne:

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

De hová tegye? Nem belső Project, vagy szerkesztő, igazad van, vagy lesz, hogy hozzáférjenek a tárhelyek és ez nem jó. A fenti kódrészlet lazán összekapcsolt, de nem újrahasználható saját. Éppen most elérte a határait Repository minta.

Következik egy adapter réteg az alkalmazás, egy közös forrás tárolók ( StaticServiceWrapper), és vagy valamilyen EditorAdapter tárgyat (vagy aggregált vagy bármi mást hívják őket), vagy most is belekeverjük kiterjesztése módszerek, amelyek lehet beszélni bármilyen és minden szükséges tárolók folyékonyan. Nem tettem, hogy pontosan ezen a módon a termelési rendszer, hanem, hogy mutassa meg a tömör példa:

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

Alapvetően, ha a GetAll, GetById, hozzáadása, frissítése, eltávolítása objektumtára megtörtént, akkor megvan, hogy hagyja el a szövetség egyedül, és lépni a tárgyat / réteghierarchia a szórakoztató részek, mint adapterek és Gyorsítótárazza és az üzleti logika ( „Oh én!” ).