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.

Commenti

Posta un commento

Post popolari in questo blog

Cancellazione fisica vs cancellazione logica dei dati

Finalmente dopo lungo tempo trovo il tempo di bloggare qualche "inutile sbrodolata"... L'altro giorno mi trovavo presso un cliente che, giustamente, lamentava problemi di performance su un applicativo. La discussione è stata piuttosto lunga e si sono toccati tanti temi; fino a che non si arriva alla fatidica domanda che ha fatto scaturire questo post: "Ma questo software utilizza la cancellazione fisica dei dati oppure la cancellazione logica?". "Logica...", rispondo io. E lui: "Per quale motivo è stata fatta questa scelta? Non è che i motivi di questa lentezza sono causati da questa scelta?". Rapidamente ho dovuto "radunare le mie forze", e ricordarmi tutti i motivi per cui, anni fa, ho intrapreso questa strada come "default" per i miei progetti (con le dovute eccezioni). A seguire, vi riporto quello che i miei 4 neuroni sono riusciti a partorire dopo la riflessione... «Quando si esegue la progettazione di un siste
Continua a leggere

Restore di un database SQL Server in un container Docker

Immagine
Qualche giorno fa un collega aveva la necessità di eseguire il restore di un database creato con  Microsoft SQL Server 2016  in locale, in modo da poter eseguire la creazione di una dashboard in PowerBI. La nostra scelta di team - ormai da anni - è stata quella di installare sui nostri computer meno strumenti possibili, e solo quelli essenziali per portare avanti il lavoro quotidiano. Meno strumenti su un computer = meno spazio disco consumato = più risorse disponibili; quindi la scelta è sempre quella di appoggiarci a risorse ospitate  in cloud . In questo caso lo scenario era più complesso, e il semplice restore del nostro backup di database nel cloud, non sembrava essere la soluzione più performante, specialmente per via dell'obiettivo che avevamo - ovvero un'  analisi dei dati  - in un ambiente di sviluppo. Quindi quello che ho cercato di fare è semplicemente prendere il backup in questione - che nel nostro esempio sarà il file  test.bak  - e fare il suo restore in u
Continua a leggere

Costruire una DataSession custom con Chakra.Core

Lo scopo primario del framework Chakra è sempre stato quello di fornire delle strutture e guidelines per la scrittura di applicazioni enterprise che fossero al tempo stesso robuste , modulari e facilmente manutenibili nel corso del tempo. Ma, visto che il tutto è farina del mio sacco, e che mi ritengo uno sviluppatore assolutamente nella media, non ho mai pensato che bastassero un pugno di classi ed interfacce per mettere in piedi una struttura tanto ambiziosa. E’ con questo spirito che va approcciato questo framework. Farsi aiutare da alcune linee guida che indirizzano lo sviluppo, con la maggior parte del lavoro demandata alle qualità dello sviluppatore che scrive il codice: è lui l’unico responsabile della qualità del prodotto finale. In questo post il mio scopo è mostrare come è possibile utilizzare alcune delle interfacce “meno conosciute” contenute in Chakra, per realizzare un provider custom di accesso dati. L’obiettivo è realizzare una di quelle feature tanto care a Chak
Continua a leggere