Pensieri a ruota libera sulla modellazione di un archiettura a provider ...

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

Print

Comments on this entry:

# re: Pensieri a ruota libera sulla modellazione di un archiettura a provider ...

Left by Emanuele DelBono at 06/08/2006 22:12
Gravatar
[(...)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(...)]

Non è quello che faccio di solito ma il concetto è simile.
Spesso nelle mie app, apporto una semplificazione, tutti i provider appartengono ad una stessa "categoria" e come tali sono tutti provider di SQL Server o tutti provider di Oracle.
In pratica invece di avere un Abstract Factory per la creazione dei provider mi basta un Factory Method.
E' una semplificazione, ma come dici tu, non mi sono imbattuto in casi reali in cui devi salvare i Customer su Oracle e gli Employee su SQL Server.

# re: Pensieri a ruota libera sulla modellazione di un archiettura a provider ...

Left by M.rkino at 07/08/2006 00:26
Gravatar
Quello che mi sto chiedendo è se ha senso che il consumer usi esplicitamente i provider delle singole tabelle o sia meglio avere una facade che espone le funzionalità legate a tutte le entità del sistema (la facade Northwind espone quindi - ad esempio - sia FindCustomers sia FindEmployees). I vari pattern table e/O le CRUD e/O sistemi ORM di persistenza - se il sistema concreto si interfaccia ad un database - sono quindi da incapsulare nel provider concreto del sistema. Anche la parte business - validazioni spicce a parte - rientra quindi nella parte puggabile... insomma una scelta un pò diversa dal solito ma non credo del tutto assurda ;-p Qualcosa che potrebbe essere interessante valutare...
Comments have been closed on this topic.
«novembre»
domlunmarmergiovensab
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011