66 messaggi dal 14 novembre 2005
Ciao,
ho una classe chiamata Utente che definisce alcune proprietà comuni a tutti gli utenti della mia applicazione oltre ad alcuni metodi.

Ho creato anche una classe Address, una classe ShippingInfo, una classe PersonalInfo, ecc.

Un' istanza di Utente potrebbe avere ad esempio, a seconda dei casi ed in fase di runtime, 1..n istanze di Address, 0..1 istanze di ShippingInfo, 1 istanza di PersonalInfo associate all'istanza principale Utente.

Volevo chiedervi quale potrebbe essere l'approccio migliore per implementare un'architettura "flessibile" che soddisfi questi requisiti, mantenendo il codice pulito e mantenibile facilmente nel tempo.

E' forse questo un ottimo problema che si può risolvere con la Dependency Injection?

Ho forse fatto una domanda troppo idiota?

Grazie cari!

br
Non esistono domande idiote, solo risposte stupide :D

Secondo me non esiste un'unica soluzione, dipende dal sistema che vuoi ottenere.
Un primo metodo potrebbe essere di esporre sulla classe Utente una Collection di Address e due istanze di tipo ShippingInfo e PersonalInfo. Se tratti Utente come un "semplice" DTO potresti limitarti ad esporli come normali properties e lasciare alla logica dell'applicazione il compito di istanziarle ed usarle.

Un altro sistema potrebbe essere di non legare affatto le classi, ma inserire in quelle accessorie un riferimento all'utente (l'ID ad esempio). In pratica una volta ottenuto l'istanza di Utente, usi una classe manager per leggere (ad esempio) gli Address che sono collegati a quell'Utente in base all'ID. Praticamente è un modello moooolto marcato su una struttura DB.

Un'altra alternativa è usare un sistema di Component-Based entities, qualcosa tipo questo: http://entropyinteractive.com/2011/02/game-engine-design-component-based-entities/
ma credo che così complicheresti troppo le cose :)

Davide Guida
Technical Architect @ Razorfish Healthware
http://davideguida.altervista.org
66 messaggi dal 14 novembre 2005
Grazie Mizrael,
in effetti stavo già implementando la prima soluzione.
Magari non per questa volta perchè sono già troppo avanti ma mi piacerebbe separare ulteriormente. Ci penserò....

ciao

Br
Per quel poco che ho capito di architettura e pattern, la separazione è utile quando i moduli sono diversi, in questo caso mi sembra di restare sempre all'interno del modulo "anagrafica"... Quale sarebbe l'utilità della DI?!

Non hai veramente capito qualcosa fino a quando non sei in grado di spiegarlo a tua nonna.
-Albert Einstein-
La separazione è SEMPRE utile. Immagina di dover creare una pagina archivio di utenti. Poi magari devi creare un box sempre visibile nella master page con la lista degli ultimi utenti iscritti. Senza un modulo di BL sei costretto a replicare in continuazione il codice.

In alternativa, supponi di dover lavorare "solo" alla GUI di un progetto, perché non hai ancora i dati a disposizione. Usando una BL "fake" puoi iniziare a strutturare un'interfaccia comune da fare usare alla GUI e che poi puoi sostituire appena hai a disposizione il Data Layer reale.

Il principio di base è sempre il DRY :)
http://en.wikipedia.org/wiki/Don't_repeat_yourself

Davide Guida
Technical Architect @ Razorfish Healthware
http://davideguida.altervista.org
Mi sono espresso male, non la intendevo la separazione in layer e/o il ricorso a sorgenti dati fake, ma l'uso della D.I./I.O.C. o interfacce in classi cosi legate tra loro.
Non credo che utente, address, shipping etc. vengano gestite da moduli separati dell'applicazione, mentre un eventuale classe order potrebbe essere in un modulo separato ed allora l'uso della D.I./I.O.C. O di interfacce sarebbe auspicabile

Non hai veramente capito qualcosa fino a quando non sei in grado di spiegarlo a tua nonna.
-Albert Einstein-

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.