170 messaggi dal 18 gennaio 2008
Ciao a tutti,
nell'applicazione su cui lavoro(applicazione .net wpf) la fonte dati è costituita da dei webservice java. Questi servizi quindi per essere usati da .net vengono rimappati con una utility .net (svcutil) che non fà altro che generare i proxy. A questo punto però per rendere disponibili le entità di dominio, ogni volta che viene modificata una entity, vengono lanciati manualmente degli script(T4) che praticamente rigenerano tutte le classi del dominio(riscivendo testualmente tutte le classi). Al di là di eventuali ottimizzazioni degli script, questo sistema ha senso? o ci sono strade più corrette? A me che il dominio sia rigenerato da degli script statici un pò mi fà rabbrividire. Che ne pensate?

Grazie
Ciao.
Per come la vedo io, il service layer dovrebbe starsene rigorosamente fuori dal Business Layer.
Trovo quindi errato l'approccio per il quale il prodotto di una ws-request dovrebbe rappresentare il tuo "dominio", per una lunghissima serie di ragioni.
Il punto è che, come fai notare, dovrai costantemente garantire la sincronia tra le implementazioni dei proxy e quelli che lato WCF, ad esempio, vengono definiti "Service Contracts".
E non si scappa! :-)
Ti dico come faccio io.

Innanzitutto, cerco di disegnare il service layer in modo che le sue operazioni siano il più "fine-grained" possibile.
E poi, utilizzo i DTO.
Trovi qualche informazione al seguente link:
Data Transfer Object

In ultimo, da un pò di tempo mi avvalgo di quello che è stato definito un "Request/Response Service Layer".
E, siccome sono pigro, ricorro a questo strumento:
Agatha Request/Response Service Layer

Spero di esserti stato di aiuto.
E occhio ai domini anemici! ;-)
Modificato da naighes il 05 agosto 2011 08.38 -

Nicola Baldi
"Make things as simple as possible, but not simpler."
>>> My blog <<<
170 messaggi dal 18 gennaio 2008
Ciao, grazie del tuo post. Anche qui usiamo i dto che poi vengono trasformati in entity dagli script che replicano un interfaccia piú o meno standard con delle class extended per le eccezioni. Questo lo trovo terribile!
Stasera studieró il framework che mi consigli per "Request/Response Service Layer". Ma riesci solo a dirmi se e come questo framework garantisce la sincronizazione delle entity con i dto che vengono da java?

Grazie
Tommaso


naighes ha scritto:
Ciao.
Per come la vedo io, il service layer dovrebbe starsene rigorosamente fuori dal Business Layer.
Trovo quindi errato l'approccio per il quale il prodotto di una ws-request dovrebbe rappresentare il tuo "dominio", per una lunghissima serie di ragioni.
Il punto è che, come fai notare, dovrai costantemente garantire la sincronia tra le implementazioni dei proxy e quelli che lato WCF, ad esempio, vengono definiti "Service Contracts".
E non si scappa! :-)
Ti dico come faccio io.

Innanzitutto, cerco di disegnare il service layer in modo che le sue operazioni siano il più "fine-grained" possibile.
E poi, utilizzo i DTO.
Trovi qualche informazione al seguente link:
Data Transfer Object

In ultimo, da un pò di tempo mi avvalgo di quello che è stato definito un "Request/Response Service Layer".
E, siccome sono pigro, ricorro a questo strumento:
Agatha Request/Response Service Layer

Spero di esserti stato di aiuto.
E occhio ai domini anemici! ;-)
Modificato da naighes il 05 agosto 2011 08.38 -
Ciao.

Anche qui usiamo i dto che poi vengono trasformati in entity dagli script che replicano un interfaccia piú o meno standard con delle class extended per le eccezioni. Questo lo trovo terribile!


Sinceramente, non ho capito molto bene a cosa ti riferisci quando citi un'"interfaccia più o meno standard".
E' chiaro che non ho un quadro di quello che è il problema che ti trovi ad affrontare, ma io personalmente tendo a vedere un DTO come un qualcosa che deve essere "wrappato" all'interno di un messaggio.

Al seguente link è spiegato questo tipo di soluzione:
Patterns for Flexible WCF Services

Tutto questo, ovviamente, concerne il design del service layer.

Per quanto riguarda il mapping DTO/Entity e viceversa, puoi ricorrere ai Factory Method.
Ovviamente, non arriverai mai a scongiurare le problematiche derivanti dai breaking changes di cui sono affetti i DTO, ma limiterai l'impatto in termini di "modifiche da apportare al tuo Dominio".
Il mio consiglio è incapsula, incapsula e ancora incapsula!
Lavora per behavior e "nascondi" il più possibile lo stato della tua entity (ovvero, usa le proprietà il meno possibile).

Per quello che riguarda il mapping, prendi in considerazione "AutoMapper":
AutoMapper

Insomma, mettendo assieme tutte le risorse che ti ho indicato, per quella che è la mia esperienza arrivi a conseguire ottimi risultati in termini di riduzione dell'accoppiamento tra DTO e entità del dominio.

Fai qualche prova e magari parti proprio con qualche Unit Test.
In questo ambito, seguire una via "TDD" (seppur parzialmente) ti aiuta ad avere maggiore lungimiranza.

Ovviamente, IMHO.

Nicola Baldi
"Make things as simple as possible, but not simpler."
>>> My blog <<<
170 messaggi dal 18 gennaio 2008
Grazie. Proveró a studiarmi tutto e costruire una soluzione migliore per il progetto a cui lavoro.

Grazie ancora

naighes ha scritto:
Ciao.

Anche qui usiamo i dto che poi vengono trasformati in entity dagli script che replicano un interfaccia piú o meno standard con delle class extended per le eccezioni. Questo lo trovo terribile!


Sinceramente, non ho capito molto bene a cosa ti riferisci quando citi un'"interfaccia più o meno standard".
E' chiaro che non ho un quadro di quello che è il problema che ti trovi ad affrontare, ma io personalmente tendo a vedere un DTO come un qualcosa che deve essere "wrappato" all'interno di un messaggio.

Al seguente link è spiegato questo tipo di soluzione:
Patterns for Flexible WCF Services

Tutto questo, ovviamente, concerne il design del service layer.

Per quanto riguarda il mapping DTO/Entity e viceversa, puoi ricorrere ai Factory Method.
Ovviamente, non arriverai mai a scongiurare le problematiche derivanti dai breaking changes di cui sono affetti i DTO, ma limiterai l'impatto in termini di "modifiche da apportare al tuo Dominio".
Il mio consiglio è incapsula, incapsula e ancora incapsula!
Lavora per behavior e "nascondi" il più possibile lo stato della tua entity (ovvero, usa le proprietà il meno possibile).

Per quello che riguarda il mapping, prendi in considerazione "AutoMapper":
AutoMapper

Insomma, mettendo assieme tutte le risorse che ti ho indicato, per quella che è la mia esperienza arrivi a conseguire ottimi risultati in termini di riduzione dell'accoppiamento tra DTO e entità del dominio.

Fai qualche prova e magari parti proprio con qualche Unit Test.
In questo ambito, seguire una via "TDD" (seppur parzialmente) ti aiuta ad avere maggiore lungimiranza.

Ovviamente, IMHO.

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.