Architettura
Design Patterns a gogo da queste parti
Premessa: ciò che scriverò è una banalità, ma secondo me in tanti non ne sono al corrente o non ci pensano. Di cosa parlo? Di cose del genere: public const int MyConst = 10;
Il danno potenziale che le costanti pubbliche possono creare alla stabilità delle nostre applicazioni è enorme.
Why? Perché le costanti non sono altro che placeholder risolti in fase di compilazione. Questo vuol dire che, finché non si ricompila, il valore non viene aggiornato.
Implicazioni?
Assembly A che definisce una costante MyConst = 10
Assembly B che referenzia Assembly A e ne utilizza MyConst
Assembly A cambia MyConst a 15
Finché non ricompilo...
Parlo di Cuyahoga, il noto CMS basato su Castle Windsor e NHibernate. Incuriosito da questo post di Ayende ieri ne ho spulciato un po' i sorgenti. E visto che li considero didatticamente interessanti, ve li consiglio. Certo, non è da prendere tutto come oro colato (il modulo del Forum, ad esempio, espone tutti i servizi in una grande, enorme, monolitica classe, che accede direttamente a NHibernate, brrrrr...) però può essere una buona sorgente per qualche idea. Tanto per dirne una, mi è piaciuta la strutturazione del Data Access Layer che sfrutta la "trasversalità" di NHibernate: IUserDao espone solo i servizi specifici dell'utente...
Posso anche essere d'accordo (anzi, lo sono decisamente) con Andrea e Dino, ma solo fintanto che li consideriamo come una sorta di guida all'implementazione. Allora sì che devo prendere spunto (giusto il paragone con le centurie), interpretandone il significato e adattandone però la struttura al mio problema specifico, magari disconstandomene fino ad avere un qualcosa di diverso. Che però non è più il pattern da cui sono partito. Credo sia un concetto parecchio importante, e che richieda pertanto un certo rigore nelle definizioni e nel significato che si attribuisce loro. Perché? Perché i pattern hanno anche un'altra importante funzionalità, oltre quella...
Volevo lasciare un commento al post di Igor, poi ne è venuto fuori un papiro e allora è meglio scrivere qui. A mio modo di vedere, c'è un errore di fondo nel concetto di DTO espresso in quel post. Un DTO, infatti, *NON* deve né ereditare, né incapsulare l'oggetto che rappresenta; anzi... dirò di più: un DTO non deve avere alcuna relazione con l'entità (o le entità) di dominio che rappresenta, altrimenti non sarebbe un DTO!! Cerco di spiegare meglio il concetto. Perché creo ed espongo un DTO? Una delle ragioni può essere che non voglio/posso esporre direttamente una mia entity...
In questi giorni, insieme al mio team, ci stiamo cimentando nella realizzazione di un progetto piuttosto complesso in tempi (quando mai) a dir poco strettissimi. Si tratta di una condizione piuttosto estrema, tant'è che non è stato affatto facile far digerire a tutti l'idea di pensare ad un'architettura ben fatta, di separare i compiti tra i vari layer e di scrivere gli unit test. Alla fine per fortuna il buon senso ha prevalso, e la nostra applicazione, ora come ora ha il suo bel domain model è suddivisa in layer, tutti disaccoppiati ed esposti solo tramite interfacce ...
Considero Architecture Journal una pubblicazione veramente di alto livello, che affronta argomenti complessi con una grande competenza. L'ultimo numero è dedicato alle Composite Application, con uno sguardo a ciò che le tecnologie Microsoft ci mettono a disposizione oggi (leggasi Office 2007, Smart Client Software Factory e Composite UI Application Block). Per chi non fosse abbonato alla rivista cartacea, oltre l'ovvio consiglio di rimediare a questa lacuna (è addirittura FREE!!), l'invito è di tenere d'occhio questa pagina: attualmente son presenti solo due articoli, a breve verranno pubblicati anche quelli che restano. Ciao :-)
Ancora grazie ad Emanuele per aver pensato a questa iniziativa. Farò di tutto per non mancare, perché l'argomento mi appassiona tantissimo (oltre che essere di estrema attualità). Appuntamento alle ore 21, le modalità di partecipazione sono descritte in qui.
Come fare per utilizzare il pattern SpecialCase con NHibernate?
C.p.l.
...per farci le preghierine la sera. Già, quello di Ayende su MSDN che trovate qui. Correte, leggetelo, rileggetelo, bevete un bicchier d'acqua e leggetelo un'altra volta. Strepitoso. Punto.
Il Model View Presenter è, tra i pattern relativi al
presentation layer, quello che in questo periodo mi intriga di più , perché secondo me riesce a separare la
logica di presentazione con la concreta implementazione dell'interfaccia in un
modo molto più netto di quanto non accada con il "cugino" Model View Controller.
Perché dico questo? Perché 10 minuti fa, sul divano, stavo leggiucchiando l'ultimo MSDN Magazine (o, meglio, l'ultimo che mi è
arrivato) e mi sono imbattuto in un bell'articolo di Jean Paul Boodhoo e ho
pensato di fare cosa gradita segnalandolo Come sempre, è presente anche la
versione online che potete...
Ieri Imperugo di ASPItalia ha pubblicato un post a proposito di NHibernate sul suo blog e
ne è seguita una discussione parecchio interessante con nostromo, Daniele e ricky, proseguita con quest'ultimo anche su MSN.
Un passo di tutto questo disquisire era qualcosa del tipo: "ha senso una Unit of Work in una Web Application, in cui il codice lato server è
solitamente stateless?"
Secondo Riccardo "una UoW ha il compito di creare un contesto transazionale a livello di logica applicativa, cosa che nel web per motivi prestazionali è preferibile fare in altri modi" e quindi scegliere se utilizzarla o meno dipende dai casi;...
Nel weekend ho lavorato ad una piccola libreria per
PockePC che interroga un servizio in rete per ottenere le previsioni del tempo
ed è stata un'altra occasione per esercitarsi con il Test Driven Development.
Ora, c'è da dire che sono ancora TAAAAANTO agli inizi, e che, alle volte, può
non essere immediato isolare le singole unit da testare, liberandole dalle
dipendenze che esse possono avere. Nella fattispecie, ho voluto fare in modo che
la mia classe che interroga il servizio e restituisce un oggetto che ne
rappresenta la risposta, non dovesse per forza collegarsi in rete per essere
testata.
Stavo quasi per...
Oggi in Microsoft, dopo la sessione di Andrea,
chiacchieravo un po' con il simpaticissimo Janky ed è venuto
fuori un concetto che forse a molti sembrerà scontato, ma che spesso non lo è:
realizzare un buon Data Access Layer è qualcosa di *dannatamente*
complesso. Ma tanto, eh!!
E l'aggravante è che, purtroppo, questa caratteristica è difficilmente
identificabile da chi si avvicina per le prime volte alle metodologie di
sviluppo object-oriented e all'utilizzo dei patterns (e, OVVIAMENTE,
tale categoria comprende anche il sottoscritto): il primo pensiero è che basta
buttar giù due query, utilizzare i resultset per costruire entity piuttosto che
riempire...
Oggi ho ricevuto un feedback a questo post che mi ha dato da
pensare: ultimamente mi è capitato di leggere commenti molto negativi sul modello DataSet/DataAdapter di ADO.NET, quasi che un bel Domain Model rappresenti la panacea di tutti i mali.
Il mio punto di vista, a questo proposito, è che la distinzione tra bene
e male (o tra Black and White, passatemi questa... è per celebrare il successo del nostro Francesco )
non sia sempre così netta. Chi ha letto Patterns of
Enterprise Application Architecture sa bene che è lo stesso Martin Fowler a sconsigliare il Domain Model in favore di
altri approcci (ad...