La modularizzazione di un software rappresenta uno strumento indispensabile per governare la complessità e aumentare la manutenibilità dello stesso. Questo è vero anche per i progetti realizzati in modalità model-driven: in questo caso, ovvimente, il concetto di "modularizzabilità" si applica a livello di modelli.
I punti di moularizzabilità messi a disposizione da Guigen sono i seguenti:
Questa modularizzazione si concretizza nella creazione di più file di modello, interconnessi secondo quanto descritto qui.
Di seguito vengono illustrate alcune buone pratiche per la gestione modulare di un progetto guigen.
Non è semplice definire un insieme di regole esaustive che permettano di organizzare al meglio gli AppModule che costituiscono l'applicativo: la scelta del come raggruppare le differenti schermate dipende molto dalla tipologia del progetto ma, talvolta, anche dall'organizzazione del gruppo di lavoro. Poichè gli AppModule non sono altro che gruppi di ContentPanel che hanno qualcosa in comune, è opportuno evidenziare uali possono essere i criteri di coesione che possono portare a raggruppare un insieme di ContentPanel.
Questo approccio prevede la collocazione in uno stesso AppModule di tutti i ContentPanel che realizzano una sola funzionalità. Esempio: funzione di gestione CRUD di un dato di business. L'AppModule potrebbe contenere ad esempio:
Si presta bene per quelle funzionalità che non sono realizzabili mediante un singolo ContentPanel.
Questo approccio prevede la collocazione in uno stesso AppModule di tutti i ContentPanel che realizzano un insieme di funzionalità (sottosistema) o le funzionalità legate ad un particolare profilo utente. L'AppModule potrebbe contenere uno o più ContentPanel per ogni funzonalità.
Esistono poi alcuni esempi negativi (bad practice) di strutturazione di AppModule:
La strutturazione delle schermate in AppModule comporta effetti sia sul codice generato, sia sulle configurazioni, sia sulle URL dell'applicazione.
Per quanto riguarda il codice generato vi sono i seguenti effetti:
it.csi.[prodotto].[componente].presentationit.csi.[prodotto].[componente].dtoit.csi.[prodotto].[componente].businessPer quanto riguarda l'organizzazione in namespace struts, occorre ancora dire che ciascun AppModule può essere marcato come secure. A fronte dell'eventuale presenza di questa impostazione e a fronte del nome dell'AppModule si hanno i seguenti effetti:
/[contesto]/base/[modulo]/[contentPanel].do se il modulo non è marcato come secure/[contesto]/secure/[modulo]/[contentPanel].do se il modulo è marcato come secureAggiungendo che tutte le action globali sono di default sotto il namespace secure (es. HomePage.do, Logout.do)
questa strutturazione in namespace permette la realizzazione di esposizioni più mirate tramite il web server, ad esempio permettendo di
proteggere con Shibboleth solo alcune action e altre no).
Per quanto riguarda la configurazione l'unico effetto sta nella generazione di un file di configurazione di struts per ciascun namespace, e pertanto per ciascun AppModule.
Le buone pratiche di strutturazione dei package di tipi in un qualsiasi linguaggio di programmazione si applicano anche al contesto dei modelli. Occorre tener presente che, a differenza dei ContentPanel de degli AppModule, i tipi sono utilizzabili in molte funzionalità. D'altra parte è vero che i tipi utilizzati in guigen sono destinati a contenere il model delle schermate e pertanto alcuni ComplexType sono specifici di una singola schermata.
L'effetto dell'appartenenza di un ComplexType ad uno specifico TypeNamespace è che la classe corrispondente viene generata in un sotto-package del package dto che ha il nome del TypeNamespace.
Gli ApplicationData rappresentano il corrispettivo nel mondo MDD di quello che sono le variabili applicative nella programmazione tradizionale. Pertanto le pratiche di buona strutturazione sono almeno in parte le stesse che si adottano per la definizione delle variabili nella propria applicazione.
La suddivisione in AppDataGroup rappresenta solo un raggruppamento logico dell ApplicationData utile a governare meglio la numerosità degli ApplicationData. Alcune buone pratiche di organizzazione sono:
Non vi sono effetti sul codice generato in quanto il generatore non genera nulla a fronte dell'esistenza di un ApplicationData, ma genera solo codice a fronte dell'utilizzo che di tali elementi viene fatto nelle schermate.