Il concetto di applicazione modulare non è nuovo. In passato abbiamo assistito ad una vera escalation di applicazioni modulari, o soluzioni per la creazione di applicazioni modulari. Ricordo ancora la mitica Digital Dashboard basata su componenti ActiveX… che oggi è diventata Sharepoint. In effetti le soluzioni modulari sono sempre state più presenti sul web piuttosto che nelle applicazioni client, in quanto il linguaggio HTML si è sempre prestato ad una “composition” dinamica… molto di più dei vecchi componenti ActiveX. Neppure l’avvento di .net ha migliorato la situazione, in quanto nel mondo client con Windows Forms, il modello Event-Based con code behind molto RAD e “Visual Basic 6.0” è rimasto pressochè immutato.
Con l’arrivo di WPF, però, lo sviluppo di applicazioni realmente modulari ha cominciato ad essere un traguardo possibile. Impiegando Prism questo traguardo può essere raggiunto ancora più facilmente. Il concetto di modulo è implementato in Prism grazie all’interfaccia IModule. Un modulo è effettivamente un insieme di funzionalità coordinate e correlate che offrono una o più funzionalità all’utente o all’applicazione. Il modulo non deve obbligatoriamente avere un’interfaccia grafica visibile, così come non è detto che debba avere una sola interfaccia grafica. Spesso si tende ad identificare un modulo con il suo aspetto finale (la View incorporata nella shell e mostrata all’utente) ma si sbaglia. Il modulo è molto di più; il modulo è eventi, comandi, logica di presentazione e solo in ultima istanza, aspetto grafico.
Ma perchè dovrebbe essere conveniente sviluppare un’applicazione con un approccio modulare piuttosto che con un approccio monolitico? Le motivazioni posso essere individuate tra:
- Sviluppo semplificato: isolando le funzionalità in ogni modulo, avremo molti moduli semplici che combinati assieme costruiscono qualcosa di complesso.
- Sviluppo, test e deployment isolato: è possibile suddividere in modo razionale lo sviluppo dell’applicazione modulare e distribuirlo in più team.
- Scaricamento On-Demand delle funzionalità dell’applicazione: spezzando in più parti l’applicazione non è necessario caricare tutto in memoria allo start-up.
- Controllo dell’utilizzo dei moduli basato sull’identità dell’utente: le funzionalità offerte dall’applicazione possono essere controllate in modo capillare.
Una cosa è certa: creare un’applicazione modulare richiede sicuramente uno sforzo maggiore rispetto a quello richiesto per lo sviluppo di un’applicazione “monolitica”. I vantaggi, però, non sono messi in dubbio, e vanno dalla testabilità alla netta separazione dell’interfaccia dalla logica, passando per una rigida formalizzazione delle metodologie di sviluppo
Ma allora, quali sono le linee guida per la creazione di un modulo per una Prism application?
- I moduli devono essere ignoti al resto del sistema, e devono essere inizializzati utilizzando una interfaccia conosciuta al sistema
- Non devono esserci riferimenti tra moduli; ogni modulo deve essere indipendente
- Non dovrebbero esserci riferimenti gestiti dai moduli, bensì i riferimenti dovrebbero essere forniti ai moduli attraverso tecniche di dependency injection
- La comunicazione ed i servizi impiegati dai moduli devono essere “laschi” ovvero, ancora una volta, non devono richiedere dipendenze di alcun tipo
- Evitare l’utilizzo di metodi statici che possono inibire la testabilità dei moduli
Quando si affronta il design di una serie di moduli devono essere seguiti i passi:
- Formalizzare gli obiettivi che si vogliono raggiungere impiegando i moduli
- Decidere come partizionare le funzionalità da incorporare in ciascun modulo
- Accordarsi sulla logica e sugli eventi di comunicazione che ciascun modulo deve trasmettere o ricevere
Questa fase di design è importantissima e consente di minimizzare il codice scritto e massimizzare il codice riutilizzato tra i vari moduli. In un ambiente Multi-Team, nel quale i moduli vengono sviluppati fisicamente in posti diversi e dove i test di integrazione non possono essere fatti tutti i giorni, queste linee guida sono ancora più importanti.
Concludendo, lo sviluppo di una applicazione modulare con Prism non è un’attività da iniziare senza pianificazione. L’aumento di complessità che un sistema modulare introduce nello sviluppo deve essere sempre supportato da un’attenta progettazione.