IUserType: serializzazione di un oggetto singolo

Per completezza di informazione mi sembra utile fare una piccola integrazione al mio ultimo post relativo ai custom "IUserType" di NHibernate. Quella particolare implementazione prendeva in esame una lista di oggetti da serializzare in JSON; tuttavia le situazione in cui è necessario salvare un tipo complesso "singolo", sono altrettanto significative. Per questo motivo, senza ulteriori indugi vi lascio il codice della classe "JsonObjectTypeBase di T" che permette il suo corretto trattamento. Aggiungiamo al modello "GeoLocation" di esempio una ulteriore proprietà "Data", di tipo "LocationData" che servirà per integrare delle informazioni addizionali sull'oggetto principale. Chiaramente la situazione è sempre la medesima del precedente articolo: non si vogliono eseguire operazioni di filtro su queste informazioni, ma semplicemente visualizzarle a titolo informativo. La mappatura NHibernate dell'oggetto dovrà essere anch'essa integrata della nuova proprietà (anche in questo caso utilizziamo un campo di testo con lunghezza non predeterminata); il tutto dovrà essere trattato con il tipo custom che andremo a specializzare. Per concludere, riporto la specializzazione del tipo generico "JsonObjectTypeBase" sopra proposto: Anche in questo caso, il metodo che è necessario implementare è "DeepCopy", tramite il quale è NHibernate è in grado di eseguire una copia dell'oggetto trattato.

Chiudo con una piccola riflessione sul motivo per cui un approccio di questo genere potrebbe essere più "snello" rispetto alla classica aggiunta di nuove colonne nella base dati. Sovente capita di sviluppare applicativi, più o meno complessi, dove alcuni oggetti sono corredati di una serie di informazioni addizionali che possono essere utili o meno. Sopratutto in fase prototipale, si parte con un subset di dati minimo (magari solo con le informazioni essenziali); con il passare del tempo i clienti si accorgono di aver bisogno di "questo" o "quel" dato in più, variando il set delle informazioni con elevata frequenza.

Il tutto corrisponde a numerose implementazioni che vanno a "toccare" diversi strati applicativi: presentazione, servizio, logica di business, persistenza e, chiaramente, la base dati, certamente la componente più delicata. Approcciare in maniera "lite" questo cambio di requisiti non esenta dal mettere mano al sistema, ma almeno evita che una componente fondamentale come il database sia impattata dalle frequenti evoluzioni, e sia più gestibile una integrazione e un deploy in ambiente di Produzione.

M.