[C#] Riflessione architetturale

[sneeze]

:D Buongiorno a tutti,
come molti di noi sanno spesso decidere per una architettura e per quali pattern utilizzare in fase di analisi di un nuovo progetto non è semplice.
Decidere ed arrivare fino in fondo ad una applicazione rimanendo coerenti al 100% con l'analisi fatta inizialmente è quesi impossibile, vuoi per via di analisi non fatte come si dovrebbe, vuoi per le richieste che arrivano sempre in fase di sviluppo e mai di progettazione, una applicazione subisce innumerevoli mutazioni durante il suo sviluppo.

La cosa migliore che si possa fare e arrivare ad avere per le mani un progetto con il miglior rapporto di astrazione dal codice e di granulosità del dettaglio in base a quello che è il nostro "Dominio" o, in caso di applicazioni veramente grandi, in base a quello che è l'obbiettivo del singolo mattoncino che si sta analizzando.

In ambito .net l'architettura più in voga è sicuramente la 3-tier.
Al di là delle sue varianti MVC, MVP, MVVM MVqualsiasicosa riproduce ogni volta lo stesso schema:


DataAccessLayer(DAL)

BusinessLogicLayer(BLL)

PersentationLayer


Ora mi chiedo e chiedo a voi, quali altre architetture programmatiche utilizzate frequentemente oltre al 3-tier, ne utilizzate?, non utilizzate nemmeno questi? perchè?

Guardiamo se siamo in grado di fare una discussione creativa e costruttiva. Mettiamo le nostre esperienze, lavorative e non, a disposizione di noi stessi e anche di chi si avvicina per la prima volta a questi argomenti che purtroppo non sono così diffusi causa ignoranza in materia e scarsa attenzione da parte delle aziende alla formazione continua del personale.


N.B. La discussione verte sulle architetture di programmazione (parliamo in grande) non sui pattern di creazione di design o di implmentazione altrimenti ci si perde.

[sneeze]

Proprio nessuno eh?
va bene scusatemi, evidentemente non interessa.....

[banryu79]

Proprio nessuno eh?
va bene scusatemi, evidentemente non interessa.....
No aspè, a me ad esempio interessare interessa e anche molto.
Ma non avendo mai programmato "in the large" e non essendo un professionista non ho nessuna esperienza da condividere o altro da dire se non attendere con la bava alla bocca lo scambio di post dei più esperti :sbav:

[sneeze]

Dato che ancora nessuno parla faccio io una introduzione al 3-tier, sperando davvero che qualcuno giunga in mio soccorso portando qualcosa di interessante.

Architettura Three-tier
l'architetture 3 tier è una architettura, spesso client-server,in cui l'interfaccia utente, la logica programmatica ("business rules"), e il Data layer (i dati) sono sviluppati e mantenuti separati l'uno dall'altro, spesso (ma non sempre) addirittura su macchine differenti. Il padre di questa architettura è sicuramente John J. Donovan.

La three-tier è classificata sia come architettura che come design pattern.

Oltre all'ovvio vantaggio di avere una applicazione modulare, l'architettura 3tier si propone di rendere possibile la sostituzione o aggiornamento di una delle 3 parti in maniera completamente indipendente dalle altre, vuoi per necessità di upgrade, vuoi per sfruttare alcune o una delle parti in altro modo o vuoi per la semplice risoluzione di un bug. Ad esempio una modifica del sistema operativo potrebbe produrre la necessità di modifiche alla sola interfaccia grafica, una variazione sul db può provocare modifiche solo al Data layer, una differente procedura applicativa provoca modifiche solo al middle tier.

Il "tier" intermedio può sfruttare il 3tier anche al suo interno, in questo caso si può parlare di applicazione multi-tier o n-tier.

http://upload.wikimedia.org/wikipedia/commons/thumb/5/51/Overview_of_a_three-tier_application_vectorVersion.svg/593px-Overview_of_a_three-tier_application_vectorVersion.svg.png


Arriviamo al dettaglio:

Strato di presentazione
è il livello più "alto" della nostra applicazione. si occupa ovviamente di visualizzare le nostre informazioni, è l'unica parte direttamente esposta allo user. Se concepito seriamente può e deve comunicare solo con il middle tier (Busisness logic) e mai con il Data Layer direttamente.

Middle tier (business logic, logic tier, middle tier ,application tier o logica applicativa)
Si astrae dall'interfaccia grafica, implementa tutte le nostre logiche programmatiche, fornisce le informazioni necessarie alla nostra UI (strato di presentazione) manipolandole se necessario, esegue i controlli sui dati, coerenza del dato, validazione e quant'altro e infine si occupa di dialogare con il Data layer.

Data tier
Questo strato si occupa solo di persistere e interrogare il nostro dominio (che esso sia un db sql o anche solo un file xml). questo strato mantiene le informazioni completamente astratte dalla nostra logica applicativa. Eventualmente implementa logiche di caching del dato per le performance.

Occhio al MVC
A prima vista l'architettura 3-tier sembra veramente simile al MVC invece la topologia è un pò differente. La regola fondamentale del 3-tier è che la presentation layer non può mai arrivare direttamente al dato ma deve per forza passare dal middle tier, sostanzialmente il 3tier è lineare primo strato -> secondo strato -> terzo strato -> secndo strato -> primo strato. Invece MVC è triangolare: la view (presentation) invia le inormazioni immesse al controller (middle tier), il controller aggiorna il Model (Data layer), ma la view riceve l'aggiornamento direttamente dal model primo strato -> secondo strato -> terzo strato -> primo strato

Storicamente questa architettura prende piede negli anni 90 dalla osservazione del funzionamento dei sistemi distibuiti dove i tre livelli sono fisicamente separati. MVC invece si sviluppa nelle precedenti decadi ad opera della XEROX (1970 1980) e si basa sull'osservazione del funzionamento di una singola macchina.

Testabilità
Ricordiamo come abbiamo già detto che tutte le nostre logiche applicative, le nostre validazione dei dati e quant'altro risiedono nel middle tier, questo comporta direttamente che l'applicazione sia testabile direttamente senza bisogno di passare dalla UI, posso con delle unittest testare continuamente le mie validazioni, il mio dialogo con i dati, le mie logiche ecc ecc...
in sostanza l'applicazione del 3tier ci avvicina molto alla realizzazione di quella che si chiama single responsability. Molto in voga in fatto di TDD.

[Vincenzo1968]

No aspè, a me ad esempio interessare interessa e anche molto.
Ma non avendo mai programmato "in the large" e non essendo un professionista non ho nessuna esperienza da condividere o altro da dire se non attendere con la bava alla bocca lo scambio di post dei più esperti :sbav:

*

Interessa anche a me. ;)

[sneeze]

beh ragazzi.... io ci ho messo del mio adesso vediamo.
per il momento i guru del forum latitano :D

[nuovoUtente86]

Credo che relativamente al MVC, vada fatta una precisazione : come si diceva, si ha una comunicazione di tipo triangolare tra le entità ma non va confuso il model con il livello persistenza. Il modello infatti agisce ad un livello di astrazione superiore, ed idealmente può essere visto come la parte "bassa" dello strato logica (ovvero quello comunicante con il livello dati). Dualmente il controller rappresenta il sap per il livello di presentazione verso i livelli più bassi. In definitiva mentre il 3-tier è un pattern architetturale puro, il MVC (a mio avviso) va posto a metà tra gli architetturali e i comportamentali (avendo in definitiva la possibilità di operare su livelli non necessariamente standardizzati) .

[sneeze]

Sono assolutamente daccordo con te.
Associare il Model allo strato di persistenza è sbagliato, il mio era un tentativo di rendere più evidenti le differenze, in questo caso quello che si avvicina più allo strato di persistenza è proprio il model. Altra cosa è MVP per il quale, secondo me, invece è possibile fare un discorso di 3-tier. Ho ancora qualche riserva invece sul MVVM

[nuovoUtente86]

Per quello che so della variante MVP, essa non è altro che la formalizzazione dell' integrazione tra MVC e Observer in ambiente .NET. Ma alla fini fine si tratta solo di una questione meramente dialettica : se andassimo ad ispezionare la maggior parte del codice prodotto seguendo questo pattern, soprattutto in Java, noteremmo un naturale utilizzo di observer atto a fornire la comunicazione di cui sopra (deresponsabilizzando il controller dalla gestione del viewstate) e a favorire applicazione multivista. Ma ciò, in realtà, non è nulla di nuovo in quanto è un vecchio principio quello secondo cui il motore grafico deve conoscere la logica sottostante, ma il contrario non deve avvenire.
Anche il MVVM, a mio modo di vedere, non introduce nulla di nuovo. Chiarisce solo che il controller, o meglio sul controller, debba essere creato un wrapper in grado di limare le differenze concettuali tra i dati nel model e quelli trattabili dalla specifica interfaccia.
Se vogliamo trovare una differenza tra le 2 implementazioni si può notare come nella prima lo sforzo programmatico iniziale è maggiore dovendo fornire un unico strato adatto a diverse viste, mentre nel secondo approccio il software deve essere molto modulare in quanto richiede l' aggiunta di un nuovo strato (molto impropriamente "driver") per la nuova interfaccia.

[sneeze]

Se vogliamo andare nello specifico allora bisogna dire che già MVC non è altro che l'implementazione dei pattern “Mediator” e “Observer”. Per quello che riguarda MVP e MVVM in effetti non sono altro che delle varianti del MVC. Nel MVP il controller viene sotituito dal presenter. Ma al contrario del MVC il presenter è allo stasso livello della view..... Dovrebbe occuparsi esclusivamente di stare in ascolto sugli eventi generati dalla UI e dal Model e mediarli, per questo motivo mi sembra che risponda bene al concetto di separation of concern proposto dal 3-tier, difatti uno dei più grandi vantaggi del presenter è proprio serve più view. L'MVVM sostituisce al controller il VIEWMODEL che invece è poizionato al di sotto dell'interfaccia grafica e si occupa non solo delle logiche applicative ma anche dei Commends che l'interfaccia grafica può eseguire, per questo motivo non può servire più view ma occuparsi di una sola. Inoltre in questo caso i dati non vengono richiesti o inviati dall'interfaccia ma vengono mandati in pull (push) direttamente dal view model verso l'interfaccia grafica tramite il potente binding offerto dallo xaml e i concetti di Notify (INotifyPropertyChanged, INotifyCollectionChanged) e di binding twoway.
Per questi motivi forse il più "puro" dei tre potrebbe essere considerato MVP. Ad ogni modo sono certo che essendo concetti abbastanza astratti se chiedessimo a 10 sviluppatori di descriverci una possibile implementazione del 3-tier sono convinto che ne uscirebbero 10 implementazioni diverse. Probabilmente la stella polare da seguire sempre e comunque rimane la “Separation of Concerns”