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...
Full Architettura Archive