Zen Programming.it

Sviluppando una SPA (Single Page Application) ci si trova spesso a doversi confrontare con problemi di serializzazione e deserializzazione di dati in formato JSON (Javascript Object Notation), da e verso il server remoto. La tecnologia che ho scelto per il mio server-side backend è ASP.NET MVC: a mio parare la scelta più naturale e sensata per uno sviluppatore che ha un forte background .NET. In fase di sviluppo, una delle attività che maggiormente fanno perdere tempo, è proprio comprendere perchè questo o quel metodo non risponde correttamente: errore nel passaggio dei parametri, problemi di formattazione, variabili e fields passati con la denominazione errata, etc. E la problematica si ingigantisce quando ci si trova a sviluppare il backend per dei colleghi che si occuperanno solo della parte client dell'applicativo: due mondi completamente isolati, dove la firma dei metodi server rappresenta l'unico "contratto" a garanzia delle due parti. Ma i contratti e gli...

Negli ultimi mesi sto lavorando sempre più spesso nello sviluppo di applicazioni "service oriented". Sviluppare piattaforme di servizi web è sicuramente una delle cose che preferisco, perchè mi permette di lavorare molto a livello funzionale ed architetturale, e meno sulla parte front-end; quest'ultima...beh, diciamo che non è "nelle mie corde". Mi considero una capra (con tutto il rispetto per gli ovini) nella realizzazione di interfacce uomo macchina e, in generale, in tutto quello che va sotto la definizione di "user experience". In realtà con il "gusto per l'estetica" ci devi nascere; se non se ne è dotati, meglio limitarsi delle cose semplici ed essenziali, lasciando la gloria ai colleghi "web designer"... Quello che è fondamentale tenere in considerazione quando si lavora ad una piattaforma di puri servizi web, è che è necessario esporre pubblicamente solo le informazioni e le operazioni strettamente necessarie al corret...

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 a...

Nel precedente articolo ci siamo lasciati con la definizione del nostro dominio applicativo. Abbiamo introdotto l'interfaccia "IUserType" di NHibernate, utilizzata per "insegnare" all'OR/M come trattare tipi di dati non nativi e persisterli sulla base dati. Non è mia intenzione spiegare tutte le peculiarità e le sfaccettature dell'utilizzo di IUserType: ci sono moltissimi tutorial in rete (molti dei quali veramente ben scritti) che spiegano in dettaglio ogni singolo aspetto. Tuttavia, per completezza di informazione ripoterò una brevissimo estratto della definizione dell'interfaccia nuda e cruda: Essenzialmente, quello che deve essere fornito all'OR/M, per renderlo in grado di trattare il dato, è la specifica del tipo di colonna su cui dovrà persistere l'informazione stessa. Nel nostro caso l'obiettivo è salvare un oggetto strutturato in formato JSON sulla base dati: quale miglior (e conveniente) scelta se non un campo "stringa...

Non nego di aver trascurato un po' il blog in questi ultimi tre mesi; il tanto lavoro e niente vacanze, hanno influito negativamente sulla mia vena creativa. Nonostante tutto, ancora una volta, un "meraviglioso" lavoro con cui mi sto cimentando in questo periodo é fonte dell'ispirazione di questo post. Definiamo lo scenario di lavoro: ammettiamo di avere un elenco di elementi, tuttosommato semplici, che posseggono una serie di oggetti collegati. Per fare un esempio calzante, definiamo un certo numero di locazioni geografiche ("GeoLocation"), ciascuna delle quali contiene una lista di risorse ("RemoteResource"). La locazione possiede una serie di attributi (che sono di nessuna rilevanza per la questione), mentre le risorse sono composte solamente da un url assoluto, e una data di registrazione della risorse stessa. Normalmente, per la persistenza dei dati su un database, si procederebbe alla creazione di una tabella per le locazioni ("GeoL...

Come detto, in alcuni scenari legati a Silverlight, è possibile sostituire le funzionalità di WCF Ria Services con delle più “snelle” action ASP.NET MVC. L’obiettivo dichiarato è rimuovere la complessità di una piattaforma di servizi che, a volte, può risultare eccessivamente pesante da utilizzarsi in situazioni tutto sommato semplici. Se non si fa un massiccio uso del “tracking” (cioè del tracciamento dello stato di ogni modello emesso dal server), l'uso dei WCF Ria Services è rimpiazzabile con una soluzione, a mio parere, semplice e performante; una soluzione che rappresenta il giusto compromesso tra produttività e innovazione, orientata a tecnologie più moderne. Se siamo in una situazione in cui l'applicazione Silverlight (come detto, basata su WCF Ria Services) è già completa e funzionante - certo, se non volete farvi del male - vi esorterei a domandarvi se esiste una reale necessità di cambiare il meccanismo per migliorare le performance. Se invece l'applicazi...

Sto scrivendo questo post da San Leonardo in Passiria (in Südtirol...uno dei posti piú belli al mondo, a mio parere), usando il mio smartphone; ogni giorno mi sorprendo sempre di più come l'informatica fa passi da gigante, come nascono nuove tecnologie o nuove tecniche per sfruttare meglio quelle esistenti. E in questo post, nel mio piccolo, voglio condividere la mia recente esperienza in questo senso. Poche settimane fa stavamo lavorando ad una nuova versione di un applicativo rilasciato inizialmente nel 2008, basato su Microsoft Silverlight e su WCF Ria Services; naturalmente la primissima versione era basata su SL2 e .NET DataServices, poi ripetutamente aggiornato a SL3/4 e WCF Ria Services. Le revisioni successive non hanno minimamente modificato l'approccio architetturale iniziale, pur introducendo quanto di meglio era disponibile per semplificare la vita dello sviluppatore. Ma con il crescere dei dati gestititi, nel corso degli anni, il sistema ha sempre piú ...