Proseguo con la corposa istantanea passando a NHibernate (è vivamente sconsigliata la lettura a tutti i Janky deboli di cuore...), lasciandomi come ultima parte quella che più mi sta coinvolgendo.
Come probabilmente ormai tutti sapranno HNibernate è un tool per l'Object/Relational Mapping, quindi se non sono in errore il suo obiettivo è quello di farsi carico delle problematiche di persistenza di entità che fanno parte di un Domain Model.
Detto questo passo ad una considerazione personale: lo sviluppo del sistema software rimane comunque Domain Driven, non Tool Driven. Detto più terra-terra, non è il domain model a doversi adattare alle caratteristiche del tool (in questo caso NHibernate) ma piuttosto è il tool che deve cercare di prestare un servizio al domain model.
Sempre IMHO, il domain model non deve mai essere intaccato dalle necessità dei servizi per una serie di motivi che non credo sia il caso di aggiungere a questo post. Il domain model dovrebbe essere sempre pensato, progettato e realizzato in modo totalmente svincolato dai tools, servizi e scelte di design che andremo ad adottare, o meglio prevediamo di adottare!
Quindi, a mio modesto parere, è sbagliato scrivere classi di entità che contengano logica o anche solo membri dedicati ad un tool si "servizio"; non tanto per motivazioni "religiose" o da estremisti, ma proprio per l'integrità dell'OOD (che scritto da un ignorante come il sottoscritto fa anche ridere)!
Piuttosto potrebbe essere una soluzione pensare a classi derivate dalle entità (traendo spunto da Markino) che, al loro interno, contengano le necessarie funzionalità di "adattamento" al tool. Di sicuro però bisogna considerare che quest'ultima soluzione potrebbe avere un costo non indifferente.
Quindi, arrivando all'utilizzo concreto di NHibernate... (sia ben chiaro, l'intenzione non è quella di fare una "recensione" di NHibernate, nè quella di giudicarlo; sto solo facendo il punto sulla situazione attuale del mio personale approccio concreto verso questo tool).
1) NHibernate di base non gestisce lo SpecialCase (in particolare il classico "Unknow"/DBNull, visto che il "Missing" viene gestito comunque dalla logica del DAL). La soluzione comunque esiste e, come ha commentato Janky, questo particolare caso dimostra quanto sia "customizzabile" NHibernate.
2) Qui si va molto sul soggettivo, ma per chi come me sceglie (ad oggi) di utilizzare il valore DateTime.MinValue per lo special case "Unknow" di una data, si ritorna al problema di prima. In questo caso implementare la soluzione è ancora più semplice: http://blogs.ugidotnet.org/duz/archive/2006/06/01/42021.aspx
3) NHibenate utilizza sue collection tipizzate all'interno delle entità per gestire lo stato degli elementi contenuti. Questo era un problema per me, dal momento che utilizzavo nelle entità delle collection tipizzate che ereditano da CollectionBase generica chiusa sul tipo.
Oltre a questo, NHibernate non aggiunge oggetti alla collezione della nostra entità ma pretende di sostituire la collection con la sua e purtroppo (o fortunatamente) dalle guidelines di .NET (e della razionalità) si scopre che una proprietà "elenco" di base deve essere esposta in read-only.
Anche in questo caso entrambi i problemi sono stati risolti: nel primo caso Janky mi ha fatto capire come sia semplicemente più corretto definire le proprietà "elenco" come IList generica chiusa sul tipo, piuttosto che sulla CollectionBase generica (il che rende l'entità ancora più "anemica" e svincolata dal tool di sviluppo); poi nulla vieta che al suo interno si possa istanziare il membro privato con la nostra Collection tipizzata.
Questo fa si che Nhibernate possa instanziare quel membro con la propria collection, ma come può sostituirla se è in sola lettura?
Semplice e quasi banale: associando il mapping di NHibernate al membro privato invece che alla proprietà pubblica.
4) Qui iniziano i dolori per il sottoscritto: polimorfismo. Purtroppo in questo caso ho solo avuto tempo di rendermi conto del problema ma non sono ancora riuscito a trovare il tempo per cercare la soluzione.
In sostanza comunque devo ancora capire come far instanziare a NH il giusto tipo quando una tabella contiene i dati di più tipi di oggetti (es. una tabella Animali in cui la colonna del db "razza" specifica il tipo della classe da instanziare, per esempio Cane, Gatto, eccetera).
Anche in questo caso forse sono i CustomPropertyAccessor la risposta o forse esistono già soluzioni integrate in NHibernate. Dovrò andare a botte di ricerca nella nuova Piazza ORM!!!
Detto tutto ciò, il rapporto con NHibernate tutto sommato credo sia molto buono, anche se il fatto di dover affrontare e risolvere questi piccoli problemini di "adattamento" al domain model mi ha di volta in volta rallentato nell'adozione.
Beh, il 2/3 é andato... Se non mando in Overflow il blog prossimamente ci piazzo anche il 3/3!