Devo per dovere di cronaca affronare la breve discussione su tutti vari layer (ormai mi tocca) per poi arrivare alla validazione..
Riecco lo schema (cliccare per ingrandire):
(Non picchiatemi se l'ho rimesso...ce lo dovreste avere in cache no?, la prossima volta lo levo :-))
CrossCutting Concern helper class (Un titolo più breve no eh?)
Di solito vanno qui tutte le classi helper che vengono utilzzate in tutto il progetto.
Un eventuale logger (eventuale mica tanto), un gestore delle exception, varie problematiche legate alla sicurezza, e così via. Molti di questi aspetti (l'uso della parola aspetto non è casuale) sono trasversali ad ogni layer applicativo.
Poi però ci si accorge che disseminare le classi di business o di altri layer con codice inerente a queste problematiche rompe un po la regola di incapsulamento tipica dell'OOP...e ad alcuni developer rompe pure qualche altra cosa...
Per questo l'uso di un motore AOP ci viene in aiuto. Non in tutto...ma perchè farsi del male quando gli strumenti ci sono?
ad esempio i miei preferiti
AspectSharp di CastleProject e
Spring.net AOP.il jankyAneddoto sul Logger:
...un mio vecchio collega una volta mi illuminò con questa frase: "
la risoluzione dei problemi in produzione è data unicamente dalla bontà dei log applicativi".
Ci sono anomalie infatti che si verificano solo in determinati ambienti e in particolari condizioni di carico, ecco come il log ci viene in aiuto al posto di un più comodo debug laddove quest'ultimo sia impraticabile. Esempio?
Scoprire un bug tra l'applicativo distribuito sui vostri 18 server di produzione in cluster IIS connessi in balancing con altri 10 server COM+ sempre in cluster....magari su un cliente che deve garantire il 24x7 :-)....aaargh....
PS: nei feedback del primo post di questa mini serie,
Roberto mi ha dato una buona idea, e gli ho chiesto se aveva della vernice gialla o rossa...
L'ottima osservazione era: ma come si fa a capire quando un'applicazione è enterprise?...mmm...argomento di qualche altro post!
(To be continued)