Ciao,

da novizio vi chiedo un consiglio o materiale da consultare per progettare il data access layer della mia applicazione.

Voglio cominciare ad utilizzare NHibernate, ma vorrei capire qual'è la migliore soluzione dal punto di vista architetturale (se mai esiste "la" soluzione migliore).

Ad esempio, date le classi del Domain Model, in che modo è preferibile che queste si interfaccino con il DAL ?

Grazie.

liuc:

> da novizio vi chiedo un consiglio o materiale da consultare per progettare il data access layer della mia applicazione.

> Voglio cominciare ad utilizzare NHibernate, ma vorrei capire qual'è la migliore soluzione dal punto di vista architetturale (se mai esiste "la" soluzione migliore).

La tua domanda non ha molto senso: NHibernate si va gia' a collocare in una specifica idea architetturale. Comunque, cerca in rete: c'e' un'inifinita' di risorse, articoli, blog e quant'altro, dai tutorial alle soluzioni piu' avanzate. Se poi hai domande, considera che questo e' il forum di Metodologie: per dubbi relativi a NHbernate e agli aspetti tecnici degli O/RM c'e' il forum apposito ("ORM") che trovi su UGIDotNet.

> Ad esempio, date le classi del Domain Model, in che modo è preferibile che queste si interfaccino con il DAL ?

Personalmente, e in generale, sconsiglio caldamente questo approccio, nel senso che soffre di gravi vizi concettuali a monte. Naturalmente cio' non vuol dire che ti sconsiglio di procedere nella tua esplorazione, al contrario: ti invito a non abbassare il livello di attenzione, una risposta definitiva al "problema software" ancora nessuno e' riuscito a darla.

-LV

---

Julio Di Egidio
Analyst Programmer
http://julio.diegidio.name

(Peace X Love] = [++1)

liuc:

Ad esempio, date le classi del Domain Model, in che modo è preferibile che queste si interfaccino con il DAL ?

La domanda è un po ambigua, nel senso che "date le classi del Domain Model" Nhibernate o in generale un ORM (Entity framework magari) si occupano della persistenza su database, per cui il DAL è costituito dall'ORM stesso. In generale comunque si tende a racchiudere le operazioni di accesso ai dati magari con il pattern Repository<T>, che in qualche modo scherma un po il codice dall'ORM utilizzato.

Talvota si ha comunque la necessità per una classe del Dominio di interagire con l'orm per accedere al db, in questo modo parte della logica di accesso al db è presente nelle classi stesse. Questo aspetto non è assolutamente da scartare, e spesso serve per ridurre la complessità ed evitare mapping bidirezionali quando non ce ne è bisogno. Ad esempio, se il cliente ha la collection orders mappata con nhibernate, a meno di non usare tecniche particolari quando la accedi ti vengono caricati tutti gli ordini del cliente :|, questo anche solo per aggiungere un nuovo ordine. In questa situazione magari meglio usare un mapping diverso, dall'ordine al customer e mettere nel customer metodi tipo GetOrders(DateTime from, DateTime to), in questo caso il mapping è più efficiente e tu puoi ancora recuperare i tuoi ordini a partire da un oggetto customer (in questo caso la classe customer deve interagire con l'orm).

Se la precedente alternativa non piace, si può costruire una generica implementazione di repository<T> e fare magari sottoclassi specifiche quando necessarie, ad esempio un CustomerRepository che implementa repository<Customer> ma che espone altri metodi specifici per Customer.

In sostanza non esiste un unico approccio, per la documentazione ci sono molte risorse, ma consiglio la lettura del libro di jimmy nilsson, magari preceduto dal fowler ;).

alk. 

---

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

blog: Alkampfer's place

[Eng] Alkampfer's place