Simplex FORM

Simplex FORM è una libreria di classi a supporto delle funzionalità che stanno alla base di tutte le maschere applicative che è possibile costruire con il framework Simplex.

Le classi sono:

1. SimplexBreadCrumb: è la classe a supporto del controllo web che mostra l’attuale albero di navigazione tra le maschere di un’applicazione. Un oggetto della classe rappresenta un ramo di navigazione percorso.
2. SimplexBreadCrumbs: Classe che rappresenta una collezione di oggetti di classe SimplexBreadCrumb, cioè l’albero di navigazione vero e proprio.
3.  SimplexForm: Classe base (o superclasse) dalla quale derivano tutte le maschere del framework Simplex. E’ una specializzazione della classe Page appositamente progettata per operare con gli oggetti delle classi della libreria simplex_ORM. Le informazioni gestite da una maschera derivata da SimplexForm possono risiedere o in un oggetto ORM (vedi simplex_ORM) se è prevista la loro conservazione in un database, o in un oggetto di classe SimplexFormDictionary qualora debbano semplicemente essere riutilizzate nella maschera stessa o in un’altra maschera. Nel paragrafo che segue verrà approfondita questa classe.
4. SimplexFormDictionary: Classe Dictionary (implementa IDictionary, IEnumerable) che colleziona triplette di informazioni (ID, Text, Type) che rappresentano rispettivamente l’ID di un controllo web, il valore della proprietà Text di tale controllo web ed una stringa che descrive il tipo di tale controllo web. Le triplette possono, ovviamente, essere usate anche per memorizzare qualsiasi tipo di informazione come in una normale collezione Dictionary.

Classe SimplexForm (Approfondimento)

La classe SimplexForm è la classe base per l’interfacciamento cioè è la classe base per il modello code-behind delle maschere del framework Simplex. Deriva da Page ma non è dotata di elementi grafici o di un proprio codice aspx. La classe supporta, attraverso la variabile di riferimento notevole TBL_UNDER_FORM, un oggetto di classe Simplex_ORM.Table e fornisce metodi per caricare lo stato dell’oggetto da un record di una tabella, mostrare a video nella maschera lo stato dell’oggetto, modificare lo stato dell’oggetto secondo quanto inserito nella maschera, salvare in un record di una tabella lo stato dell’oggetto.

TBL_UNDER_FORM è solo uno degli oggetti che formano lo stato di una maschera del framework Simplex. Il caricamento dello stato di una maschera avviene in fase di caricamento della maschera mediante il metodo preloadEnvironment() che è il primo metodo invocato dal gestore di evento Page_Load().

Nelle versioni più recenti è stata aggiunta la variabile notevole MAIN_UNDER_FORM che fa riferimento all’oggetto Simplex_ORM.Table supportato da un’eventuale maschera chiamante.

In Simplex lo stato di una maschera viene conservato principalmente in sessione. L’uso del ViewState per questo scopo è marginale (e desueto, cioè è presente solo nelle prime versioni di Simplex_FORM).  La Collection Session viene, quindi, usata per la conservazione dello stato e per il passaggio di informazioni ed oggetti tra la maschera chiamante e la maschera chiamata. Non solo. Ogni maschera di Simplex può accedere alle informazioni generali dell’applicazione attraverso un oggetto di classe GeneralApplication conservato in sessione. L’oggetto Session, quindi, è un oggetto fondamentale per il funzionamento di un’applicazione realizzata con Simplex.

SimplexForm non ha una propria visualizzazione e pertanto non è previsto che si possano aggiungere controlli web al suo interno. Per creare una maschera basata su SimplexForm è necessario usare una sua sottoclasse. La sottoclasse di derivazione diretta è GenericSpxForm, argomento di un dedicato articolo.

Storia delle Versioni

Versione	Data	Modifiche	Dll	Help	Sorgente
v.1.2.0.3	26/05/2018	– Corretto il BUG su getElement() – Cambiato il tipo restituito dal metodo “this[String p_Key]”.		Download

Gli elementi del framework: Le Regole

Affinché un’applicazione sviluppata con Simplex funzioni devono essere rispettate alcune regole di progettazione e di implementazione:

1. [MUST]: Il database deve essere progettato in modo consistente, cioè in terza forma normale e con tutti i vincoli intrarelazionali ed interrelazionali implementati mediante i costrutti del modello relazionale (ad esempio per il modello relazionale devono essere definiti tutte le chiavi primarie, tutti le chiavi esterne ed i vincoli di integrità referenziale, tutti gli indici ed i vincoli di unicità necessari).
2. [MUST]: Ogni tabella del database deve essere dotata delle colonne necessarie per determinare quando un record è stato creato (colonna DATA_SYS) e chi lo ha creato (colonna USR), quando un record è stato modificato (colonna DATA_UM) e chi lo ha modificato (colonna USR_UM), quando un record è stato cancellato logicamente (colonna DATA_DEL) e chi lo ha cancellato (di nuovo colonna USR_UM).
3. [MUST]:Il database deve SEMPRE avere le Tabelle che verranno illustrate in un apposito paragrafo.
4. [SHOULD]: Ogni operazione significativa dovrebbe essere tracciata nella tabella dei logs. Gli errori e le eccezioni gestite pure dovrebbero essere tracciate nella tabella dei log.
5. [SHOULD]: Ogni classe, ogni metodo, ogni attributo, ogni proprietá dovrebbe essere adeguatamente commentata.
6. [MUST]: Il passaggio delle informazioni tra una maschera e la successiva (anche se stessa) deve essere effettuato ricorrendo alla Session. Le informazioni di funzionamento di un’applicazione devono essere incapsulate in apposite classi. Le istanze di tali classi devono essere disponibili ai diversi moduli dell’applicazione nella sessione attiva.
7. [SHOULD]: Le regole business dovrebbero essere implementate al livello della gestione dei dati, cioè nel DBRMS, mediante elementi di programmabilitá quali stored procedures, trigger, etc. Quando possibile ed utile sarebbe opportuno gestire in anticipo le violazioni delle regole business o a livello di presentazione mediante regole di validazione dei dati immessi o a livello di applicazione mediante apposite classi di controllo.
8. [SHOULD]: l’applicazione web dovrebbe essere sviluppata con il criterio modulare. Nel progetto dell’applicazione .NET i sorgenti di ogni modulo applicativo dovrebbero risiedere in una sottocartella dedicata.;
9. [SHOULD]: i nomi di ogni oggetto del database (tabelle, colonne, vincoli, stored procedure) ed ogni classe dell’applicazione dovrebbero essere semantici, cioè in  qualche modo significativi ed intellegibili.
10. [SHOULD]: le maschere direttamente derivate dalla classe Page dovrebbero essere evitate.
11. [SHOULD]: Ogni programma realizzato con Simplex dovrebbe essere composto da funzioni applicative, ossia moduli applicativi specifici per ogni aspetto applicativo gestito dal programma.
12. [MUST]: Ad ogni maschera dell’applicazione DEVE corrispondere uno ed un solo record della tabella UTILS_Menu, anche se non è raggiungibile da alcun menu.

Introduzione al Framework Simplex

Il framework Simplex (brevemente Simplex) nasce con l’intento di rendere veloce ed omogeneo lo sviluppo di applicazioni web che fanno uso di un unico database.

L’impulso alla realizzazione del framework infatti deriva dalla necessitá di lavorare in una grande organizzazione dotata di molti programmi applicativi verticalizzati, cioè non cooperanti tra loro, sviluppati con diverse tecnologie, alcune delle quali tecnologicamente obsolete, e realizzati da team di sviluppatori che hanno impiegato ciascuno propri paradigmi e metodi. Questa condizione, unita alla mancanza di personale tecnico e di risorse sufficienti per la manutenzione e lo sviluppo innovativo, ha reso necessario la costruzione di uno strumento che consentisse lo sviluppo veloce di applicazioni web-based, che offrisse alcune funzionalitá di base, che raccogliesse l’esperienza maturata e la riproponesse per realizzare applicazioni modulari e facilmente manutenibili.

Le applicazioni sviluppate con il framework Simplex in modo corretto godono delle seguenti proprietà qualitative:

1. 1. Funzionalità: Dato che il framework si occupa di gestire correttamente le operazioni elementari CR.U.D., lo sviluppatore può dedicarsi alla realizzazione di funzioni il più possibile aderenti ai requisiti applicativi.
   2. Affidabilità: i modelli proposti dal framework sono operativamente collaudati e consolidati. Il rispetto delle best practies e delle regole che fanno parte del framework garantiscono un buon livello di recupero di informazioni a seguito di una perdita accidentale ed un buon grado di tolleranza agli errori.
   3. Correttezza e Robustezza: un programma realizzato con Simplex viene costruito partendo da Modelli applicativi ampiamente testati che forniscono un insieme di operazioni di base (creazione, modifica e cancellazione di record) che, se la progettazione del database rispetta i canoni e le regole previste, espletano correttamente il proprio compito intercettando e gestendo eventuali situazioni anomale.
   4. Manutenibilità: tutti i programmi realizzati con Simplex hanno la medesima struttura di base. Dunque é possibile individuare con facilitá i punti in cui introdurre codice correttivo o evolutivo. Inoltre il codice delle classi e dei modelli é commentato per facilitarne la comprensione. Tutti gli errori e le condizioni anomale, infine, vengono tracciate in una tabella dei logs in modo che sia possibile verificare le motivazioni per le quali l’applicazione presenta un eventuale comportamento non previsto.

Il framework Simplex è un insieme strutturato di elementi correlati tra loro. Tali elementi sono:

1. Regole
2. Classi
3. Modelli
4. Documenti
5. Tabelle

Nei prossimi articoli verranno esaminati nel dettaglio gli elementi costitutivi del framework. Per usare al meglio il framework è necessario conoscere bene questi elementi e come ciascuno di essi si relaziona con gli altri.

Il framework puó essere usato sia intervenendo direttamente sul codice dei modelli TEMPLATE, sia attraverso un apposito programma applicativo denominato Simplex Form Builder, attualmente in fase di sviluppo.