In "L'evoluzione nel disegno di architetture ..." ho scritto: "Le applicazioni diventano quindi consumer di Façade di sistemi che gestiscono uno scope limitato e ben definito del business applicativo. I sistemi li vedo quindi divisi in Application Layer agganciati a sistemi a loro volta composti da Façade, Entità e definizione del provider…". Dicendo questo intendo dire che un provider dovrebbe gestire a 360 gradi un atomico business... con atomico business non intendo una singola tabella ma un insieme di tabelle che costituiscono/descrivono il business... andando ad eliminare i provider a forma di "CRUD" e introducendo provider quantitativamete ricchi di funzionalità/metodi. Immaginando di implementare la classica applicazione per la gestione del database Nortwind - un HelloWorld per il test applicativo dei moderni disegni di archietture - non andrei a definire un CustomerProvider e un EmployeeProvider e via dicendo... ma mi sento di definire un unico NorthwindProvider. In liena di massima considero che ogni provider sia indipendente dagli altri e qundi mi chiedo ha senso che CustomerProvider punti ad un Oracle e EmployeeProvider punti ad un SqlServer? O meglio i dati e i processi gestiti dai due provider sarebbe davvero indipendenti?! In base ai classici casi d'uso del nostro HelloWorld dati e processi non sono indipendenti e qundi non sono sezioni applicative atomiche...
Si ma non rischiamo di avere classi troppo corpose?! Non si è sempre detto che le classi dovrebbero fare poche cose? In realtà a dicitira corretta è che le classi devono avere specifiche competenze e secondo il ragionamento appena fatto Customer e Employee rientrano nell'insieme degli oggetto Northwind... non scindibili. E' comunque vero che si riaschia di aver classi troppo corpose e qundi difficilmente gestibili... ma è sempre possibile che il provider sia a sua volta Facade di una serie di CRUD interne al package (libreria) oppure si potrebbero sfruttare le potenzialità del partial che permette di avere una classe spliittata su più file.
CustomerProvider e un EmployeeProvider sono davvero non scindibili?! In realtà dipende dai casi d'uso e dalla distrizbuzione finale delle funzionalità... è possibile che si vogliano considerare CustomerProvider e un EmployeeProvider come moduli applicativi integrabili sono su richiesta e solo in base alle reali esigenze applicative...
Alla fine questo mio post non da una risposta definitiva se meglio tenere tutto insieme o meglio dividere... ci sono pro e contro dipendenti dal contesto applicativo e dalle esigenze e/o requisiti. Il mio è ragionamento ad alta voce sulle varie - motivate - possibilità nella modellazione/disegno di un archiettura a provider...
posted @ sabato 5 agosto 2006 23:01