Introduzione
Come descritto nel mio precedente articolo TONIN 360 Cos’è e a cosa serve, questa piattaforma software vuole essere uno strumento efficace per la gestione della documentazione di commessa (elaborati grafici ed analitici, modelli BIM, ecc.). Che sia accessibile da qualsiasi località un utente si trovi, purché in possesso di:
- un device come pc, notebook, tablet, smartphone;
- una connessione internet attiva;
- idonee credenziali di accesso.
Per rispondere a queste esigenze, l’architettura della piattaforma software implementata risulta particolarmente articolata.
Essa è stata scritta interamente in C# e si basa su alcune tecnologie software disponibili sul mercato, oggi all’avanguardia, e che andrò ad illustrare brevemente nel corso del presente articolo.
In termini di architettura della piattaforma software, risulta di primaria importanza distinguere la struttura logica della piattaforma da quella fisica. In quanto i vari strati (layer) che compongono la logica del software, non necessariamente corrispondono in un rapporto 1 : 1 con la struttura fisica (hardware), dove effettivamente i primi risiedono e svolgono la propria funzione.
Struttura Logica Multi-Layer della piattaforma software
Fondamentalmente l’architettura logica della piattaforma è strutturata sui seguenti 3 livelli:
Data Layer
Ovvero repository dei dati. Implementato su piattaforma cloud Microsoft Azure, è costituito da 3 distinti repository:
- Microsoft SQL Azure Server per l’archiviazione delle informazioni strutturate;
- Microsoft Azure Cosmos DB per l’archiviazione delle informazioni non strutturate;
- Microsoft BLOB Storage per l’archiviazione dei files;
L’accesso a questi repository viene effettuato con l’ausilio delle librerie Entity Framework 6, per la piattaforma .NET e Entity Framework Core 5.0 per la nuova piattaforma .NET 5.0.
Il motivo dell’utilizzo di due framework distinti verrà descritto più avanti.
Business Layer
Strato contenente la cosiddetta ‘logica aziendale’ di implementazione e gestione delle informazioni (dati) e delle sequenze procedurali (logica di Business).
Per la stesura della Business Layer si è utilizzato il CSLA Framework (libreria Open Source creata da Rockford Lhotka) già strutturato per implementare regole di Business sui dati. Supporta in automatico la serializzazione delle classi, la NotifyPropertyChanged, Autenticazione e Autorizzazione basata su ruoli, diversi livelli di Undo e agevoli procedure di CRUD (Create, Read Update e Delete) da e per i Database.
Presentation (UI – User Interface) Layer
In questo ambito sono stati realizzati distinti sub-layer a seconda della diversa interfaccia grafica che verrà utilizzata dall’utente.
Browser
Nel caso di utilizzo di TONIN 360 con un browser (Chromium), l’applicativo è implementato su piattaforma Blazor .NET 5.0 (Server e Web Assembly).
Per un utilizzo invece, su Windows 10, è stato realizzato un applicativo Desktop stand alone basato su WPF e pattern MVVM (Model-View-ViewModel).
La stessa tecnologia è stata utilizzata per l’implementazione degli Add-In nei software Microsoft Office (Word, Excel, Outlook) e Autodesk (AutoCAD, Revit, Naviswork).
Smartphone
Infine, per un utilizzo su smartphone, l’applicativo realizzato per IOS e Android è basato su Xamarin Forms e MVVM.
Per tutte queste diverse interfacce utente si è fatto ampio uso non solo dei controlli forniti da Microsoft per le diverse piattaforme, ma anche e soprattutto dei controlli commercializzati da Syncfusion.
Questa software house infatti, mette a disposizione una moltitudine di controlli utente che coprono il normale fabbisogno di un applicativo business; con il vantaggio che i medesimi controlli sono disponibili per le diverse User Interface, semplificando enormemente tempi e codice di implementazione.
Dependency Injection
L’orchestrazione tra le diverse classi di oggetti di tipo Business, View, ViewModel è stata implementata adottando il pattern SOLID, fondamentale per la programmazione ad oggetti e soprattutto con ampio utilizzo di Dependency Injection (DI), altrimenti sarebbe stato praticamente impossibile gestire una mole così enorme di classi.
Maggiori dettagli della specifica implementazione verranno illustrati nell’ambito di prossimi articoli dedicati che verranno pubblicati in questo Blog.
Si sottolinea che alla base vi sono i motori di DI interni ad ASP.NET Core (Blazor) e Unity (PRISM).
In particolare, l’intera architettura MVVM degli applicativi Desktop, AddIn e Smartphone si basa su un ampio utilizzo di PRISM e Unity Library.
Struttura Fisica della piattaforma
Come detto, il repository dei dati è istanziato su cloud ed è costituito da Web App Serverless di Microsoft Azure quali Azure SQL Server, Azure Cosmos DB e Azure BLOB Storage.
Trattasi di servizi web per l’archiviazione messi a disposizione dalla piattaforma Microsoft Azure e che, per funzionare, non richiedono l’implementazione e la manutenzione di Server Host dedicati (fisici o Virtual Machine).
L’accesso a questi servizi avviene esclusivamente attraverso altre due App Web Service, di mia realizzazione, e residenti sempre su Microsoft Azure.
Queste due App hanno il compito di gestire le richieste inoltrate dai vari client, trasferendo i dati da e per i suddetti repository.
Le due App Web Service svolgono sostanzialmente il medesimo lavoro e colloquiano con le diverse App client utilizzando i protocolli tradizionali di trasmissione dati, in questo caso gestiti direttamente da CSLA (WCF e WEB API).
Sull’App Web Service gira la versione Server della Business Library Layer; mentre sui client è implementata una versione più leggera della business class library.
Le due App Web Service si differenziano tra di loro solo per il diverso target .NET. Una prima storica App Web Service gestisce le richieste dei client di tipo legacy, ovvero la cui architettura si basa su .NET framework 4.X e .NET framework Standard 2.0, come ad esempio l’App Desktop, gli AddIn e l’App per gli smartphone.
La seconda App Web Service, implementata in questi ultimi due mesi, è fondata sulla recente radicale revisione di .NET 5.0, in ottica cross-platform, e gestisce la versione dell’applicativo accessibile da browser (Server side e Web Assembly).
È superfluo evidenziare che vi sarà una graduale migrazione dei client di TONIN 360, verso un’unica e uniforme base di codice fondata su .NET 5.X – 6.X e, di conseguenza, la progressiva dismissione delle App che attualmente girano su .NET 4.X, compresa la prima App Web Service.
Struttura multi-progetto del Codice
In un mondo come quello dello sviluppo software che si evolve -come in quest’ultimo decennio- con una velocità impressionante, non è semplice stare al passo. Soprattutto quando le nuove tecnologie e le versioni dei vari framework non sono compatibili con le precedenti.
Ciò accade generalmente per questioni di performance, ma comporta, per il povero sviluppatore, molto tempo ed impegno per analizzarne le nuove funzionalità, le modalità di implementazione e, quindi, la progressiva riscrittura del codice e successiva fase di test.
Con la commercializzazione del nuovo .NET framework 5 Microsoft ha finalmente imboccato la strada di una seria revisione del framework in un’ottica cross-platform che consentirà, in un prossimo futuro (si spera) di scrivere un unico codice sorgente (magari!) che possa girare su diverse piattaforme, sistemi operativi e quindi devices, lasciando al framework gestire le diversità.
Siamo ancora all’inizio di questa fase che si annuncia come un cambiamento epocale nello scrivere software e che dovrebbe semplificare enormemente lo sviluppo di applicazioni business e non solo.
In attesa che ciò diventi di dominio pubblico, la progettazione del software che ambisca ad una sorta di cross-platform deve scontrarsi e gestire le diverse modalità di implementazione che necessariamente emergono fra le varie piattaforme.
Frammentazione del Codice
Ciò comporta una frammentazione più spinta del codice in sub-progetti, che va oltre gli strati (layer) sopra descritti.
Alla base vi è un’analisi e una conoscenza approfondita delle piattaforme, dei software all’interno dei quali i client di TONIN 360 devono girare, al fine di consentire una logica di raggruppamento del codice condiviso in sub-progetti shared. Differenziando solamente le parti specifiche che andranno a far parte di ulteriori sub-progetti distinti.
La scelta di adottare librerie e framework come CSLA, Unity, Prism, controlli UI di Syncfusion, Xamarin Forms, che già sono strutturate secondo questi indirizzi, ha certamente favorito e semplificato la realizzazione di TONIN 360.
Ciò non toglie che ad oggi, come si evince dalla figura allegata, il codice sorgente di TONIN 360 è costituito da ben 327 sub-progetti. Molti di questi sub-progetti sono destinati, nei prossimi anni ad essere sostituiti e uniformati, man mano che la conversione del codice da .NET 4.X a .NET 5-6 verrà resa pubblica, andando verso un unico framework per tutte le piattaforme.
Stay tuned.
Commenti recenti