Benvenuto/a Entra | Registrati | Aiuto
in Cerca

Persistance ignorance ok, ma...

Ultimo post 22-07-2008, 18:26 da parte di alkampfer. 1 risposte.
Ordina i post: Precedente Successivo
  •  22-07-2008, 17:20 1961

    Persistance ignorance ok, ma...

    Si parla tanto di PI, di POCO, di domain model "anemico" ecc...

    Personalmente i miei oggetti del dominio hanno comportamento e quindi
    metodi che però rimangono chiusi all'interno del dominio (per capirci
    l'assembly del domain model non ha riferimenti ad altri assembly se
    non quelli base del .NET fx).
    Che metodi sono?
    Metodi che servono per fare operazioni di validazione sugli oggetti,
    oppure metodi che fanno calcoli e/o  ordinamenti di collezioni in
    memoria, oppure metodi che servono per aggiungere oggetti a collezioni
    (il classico AddChild(Child c)).
    Sulla mailing list dedicata al DDD è ripartita una annosa discussione
    sul fatto se sia o meno importante che il dominio sia completamente
    ignorante sul resto del mondo.
    Qualcuno dice che i suoi oggetti del DM usano i repository (tramite
    delle interfacce IXyzRepository) per compiere operazioni sui dati. Voi
    come vedete la cosa?
    Io tempo fa la vedevo come il male, oggi ho un atteggiamento un po'
    più morbido perchè non trovo troppi problemi di manutenibilità e/o
    design...anche se non ho ancora fatto un DM in questo modo...qualcuno
    ha esperienza in merito?
    Alla fin fine vuol dire che il mio oggetto Fattura può avere un
    riferimento al repositori IFatturaRepository per caricare quando serve
    l'elendo dei dettagli, o per eseguire una query per calcolare
    l'importo totale.

    Che ne dite?


    ---
    ema
    http://blogs.ugidotnet.org/blogema
  •  22-07-2008, 18:26 1962 in risposta a 1961

    Re: Persistance ignorance ok, ma...

    Personalmente ritengo che i Repository siano oggetti di infrastruttura, e per questo siano accessibili agli oggetti di dominio. Tra l'altro per limitare le relazioni tra gli oggetti questa cosa è utile. Ad esempio non ha molto senso che l'oggetto Customer abbia una lista di Orders, anche perchè ogni qualvolta che la chiamo mi carica tutti gli ordini, sarebbe più efficiente mettere nell'oggetto Customer metodi per recuperare particolari categorie di ordini, per fare questo naturalmente il Customer deve poter accedere al repository.

    alk. 


    --
    Non esiste vento favorevole per il marinaio che non sa dove andare. (Seneca)

    blog: Alkampfer's place

    [Eng] Alkampfer's place
Visualizza un feed RSS in XML
Powered by Community Server [Telligent Systems]