jankyBlog

...effettivamente io non dovevo scrivere niente del genere, ma è stata tutta colpa dell'autobus ieri che ha ritardato...:-)
Stavo preparando un paio di post per condividere un lavoro che ho fatto molti mesi fa riguardo ad un framework(ino) di validazione semplice ma molto efficace, e per proporlo stavo disegnando il solito grafico dei layer e delle varie dipendenze...poi è uscito fuori il mostro:

(clicca per ingrandire)

:-) a me serviva solo la parte dove si vede il Validation API, ma visto che è venuto così carino 4 chiacchiere sul mio modo di vedere le cose le faccio volentieri:

Premessa:
Ovviamente non mi sono proprio inventato niente, questa è solo la mia (janky)vision di come praticamente strutturo le applicazioni di fascia enterprise, visto che di varianti ce ne potrebbero essere tantissime (vedi un domain layer inlcuso nel business, uno userinterface layer incluso nel presentation, AOP si AOP no, ORM si ORM no..).
Vediamo qualche considerazione su ogni layer...

Presentation Layer
Poco da dire: è assolutamente vietato scrivere logica di business in questo livello ma questo lo sanno anche i muri. Per esperienza personale vi dico: il tempo che si può perdere nel debuggare, testare le form (sia windows, web, mobile o quello che volete voi) è veramente impressionante. Ecco perchè in questo livello non ci dovrebbe neanche essere la logica di flusso di navigazione.
il jankyPensiero sul Presentation Layer: per ogni riga di codice superflua sul Presentation far pagare 10 euro al programmatore.

UserInterface Process Layer
Qui possiamo wrappare un qualsiasi tool MVC che ci aiuta nello sviluppo, fate voi
per la parte web: MonoRail su tutti, purtroppo NStruts non è all'altezza del colosso di jakarta,
per la parte windows, il nuovo CAB (Composite UI Application Block) o il più vecchiotto UIP Application Block.
il jankyPensiero sullo UserInterfaceProcess Layer: non fatevi confondere le idee, l'MVC è una cosa seria, è il PVC quello che inquina...

Domain Layer
Qui il dominio di conoscenza del vostro cliente prende la forma di classi pure.
Il domain model di Fowler recita: "...le classi devono contenere dati e comportamento...", io sono un po più fedele al Domain Driven Design che dice che le classi di dominio dovrebbero essere il più possibile anemiche, solo property e pochi/niente metodi. Se voglio implementare un qualsiasi metodo/azione, uso la validazione e un command pattern sul Business Layer.
Il domain layer è conosciuto (non in senso biblico) da tutti i layer dell'applicazione, trasversale a tutti. Avendo pochi metodi il suo legame agli altri layer non introduce problemi di uso improprio! :-)
il jankyPensiero sul DomanLayer: Il più bello, il più astratto...il più sexy!

(To Be continued)