Architettura

Costanti pubbliche? AHIAHIAHI

Marco De Sanctis — Thu, 31 Jan 2008 16:15:13 GMT

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 Assembly B, questo continua a vedere MyConst = 10

Ogni tanto mi capita di trovare righe di codice simili a quella in alto, con seguenti bug "strani" e dolori per scovarli. Ecco perché cerco sempre di abituare i junior che lavorano con me alla regola:

Le costanti devono essere sempre private o internal. Se serve esporle allora si utilizzino dei field readonly.

Augh!

Technorati tags: Costanti, Readonly field

Un buon esempio di IoC e separation of concerns

Marco De Sanctis — Thu, 29 Nov 2007 13:12:28 GMT

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 (es. Autenticazione, GetByUsername), mentre i servizi generici (GetById, ListAll, ecc.ecc.) sono forniti da ICommonDao, che però avrei preferito sfruttasse i generics.

Magari se non avete nulla di interessante da leggere nel vostro feed aggregator, dateci un'occhiata!

Technorati tags: Architettura, NHibernate, Castle Windsor

I pattern sono come le centurie di Nostradamus?

Marco De Sanctis — Mon, 26 Nov 2007 17:47:38 GMT

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 di darci una traccia (più o meno aderente alla realtà) ad un problema ricorrente. Ossia quello di rappresentare *un dizionario*, un linguaggio che permetta a due progettisti di capirsi al volo quando parlano di un aspetto del design. E allora in questo caso la definizione dovrebbe essere precisa, talmente precisa da essere sicuri che se io propongo ad Andrea di soddisfare quel requisito tramite un Layer Supertype, o di utilizzare un DTO per esporre i dati all'esterno, o di gestire la persistenza tramite un Active Record (BUAHAH ecco che ci siamo), io e Andrea dobbiamo capirci al volo, senza nessun rischio di misunderstanding.

E allora dire che questo framework "è quasi un Active Record" mi fa storcere un po' il naso, perché o lo è o non lo è. Punto.

Tra l'altro, credo proprio che Linq To SQL sia un perfetto esempio di DataMapper, anzi, di MetaData Mapper, e che di Active Record non abbia proprio nulla. Perché, visto che citiamo Fowler, allora lui stesso descrive Active Record come

An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.

My two cents...

Technorati tags: Architettura, Pattern, Active Record

WCF, DTO, Fatture e RapportinoMaker (TM)

Marco De Sanctis — Tue, 30 Oct 2007 01:33:30 GMT

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 di dominio. E allora che senso ha creare un DTO che la incapsula? o da cui eredita? Finirei comunque per esporla, no?

In realtà, il DTO ha un significato più ampio: è semplicemente un modo per codificare un particolare messaggio rappresentandolo in forma di oggetto, e non necessariamente è mappato 1-1 con le entità di un domain model (diciamo pure che in generale, ha decisamente poco a che vedere con esse).

Nel caso di Igor, volendo creare un DTO per l'oggetto Fattura, probabilmente realizzerei qualcosa del genere:

 1 [DataContract]
 2 public class FatturaDTO
 3 {
 4   [DataMember]
 5   public string Numero;
 6   [DataMember]
 7   public DateTime Data;
 8   [DataMember]
 9   public string RagioneSocialeCliente
10   ...
11 }

(notare la proprietà RagioneSocialeCliente), magari con un costruttore che accetti un'istanza di "Fattura" e popoli i relativi field. Le stringone XML di questo esempio di Igor sono anch'esse dei DTO, magari in senso lato (ma neanche troppo).

BTW, sicuramente si tratta di un approccio dispendioso, che personalmente adotterei solo se ho vincoli che mi impongono una SOA rigorosa. Mi capita spesso, nel lavoro di tutti i giorni, di dover esporre servizi a client Java o PL/SQL, o magari di esporli e basta, senza sapere chi mai li invocherà, con in mano solo un documento di specifiche di forma da rispettare. E in quel caso allora è necessario specificare un insieme di messaggi che standardizzino il protocollo di comunicazione con i miei servizi e che restino immutabili anche a seguito di eventuali modifiche che un giorno farò al mio domain model. I DTO, per l'appunto.

Molto spesso però - e questo mi sembra proprio il caso di Igor - la reale necessità non è quella di esporre servizi a terze parti, ma semplicemente quella di avere un'applicazione distribuita, pur mantenendo stretto controllo di ciò che è in esecuzione sul client e sul server. Per dirla in parole povere, me ne frego dell'interoperabilità e non espongo nulla a nessuno, voglio solo avere la possibilità di interfacciarmi da remoto con una parte della mia applicazione.

Ottimo. Beh, in questi casi non vedo controindicazioni ad utilizzare direttamente le entity del domain model, se possibile. Dirò di più, magari voglio avere gli stessi tipi di oggetti sia sul client che sul server. Di SOA non ha neanche la più lontana parvenza, ma chi se ne frega? non mi serve avere un'architettura orientata ai servizi.

Allora, in uno scenario simile può essere utile anche questo tip.
http://blogs.ugidotnet.org/Crad/archive/2007/04/02/74468.aspx

Ah... last but not least: invece che con DataContract, i servizi WCF funzionano benone anche con entity marcate semplicemente come Serializable.

Technorati tags: WCF, DTO, SOA

Per quelli che... "l'architettura è solo frizzi e lazzi"

Marco De Sanctis — Fri, 16 Mar 2007 02:05:00 GMT

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
fa uso di inversion of control, dependency injection e aspect oriented programming

Quali vantaggi *PRATICI* e quale *RISPARMIO* (in termini di fatica e tempo) ci ha portato l'evitare di buttar giù la testa e mettersi a scrivere codice?

Sul punto 1 non mi soffermo, è oramai piuttosto noto come il modello tabellare mal si adatti a variazioni dell'informazione da trattare, cose che capitano spesso, soprattutto nelle fasi iniziali di un progetto, in cui i requisiti non sono ancora perfettamente definiti.

Passiamo al punto 2. La suddivisione in layer ha consentito di dividere il nostro team in diversi gruppi, che si sono concentrati separatamente nello sviluppo delle rispettive librerie.

Il team del DAL ha lavorato a stretto contatto con il responsabile dello sviluppo su DB Oracle.

Il team del BL, proprio grazie al fatto che il DAL è esposto tramite interfacce, ha potuto sviluppare la libreria di propria competenza senza che il DAL esistesse, facendo uso di Test Driven Development e di mocking.

Idem dicasi per il team che si è dedicato al presentation layer.

Prima conclusione: creare interazioni loosely-coupled consente di parallelizzare il processo di sviluppo. Con librerie fortemente accoppiate, sarebbe stato un dannato incubo.

Punto 3. Lo scenario di deploy sarà sicuramente distribuito: il database non sarà direttamente esposto al web server su cui girerà la nostra applicazione, che dovrà pertanto interagirvi tramite web service. Ottimo. Peccato che attualmente

Non c'è tempo per realizzarli
Ancora non è chiaro quale tecnologia utilizzare (WCF? WSE? ASP.NET?)

Ma a noi cosa ci frega? I layer comunicano esclusivamente tramite interfacce, quindi posso usare tutta la inversion of control che voglio: al momento, in cui non ci sono risorse da dedicare allo sviluppo dei web service, espongo direttamente le librerie che connettono i vari strati; domani, quando ci sarà più calma, realizzerò lo strato di trasporto, che esporrò tramite le stesse interfacce ed in maniera del tutto trasparente ai layer utilizzatori: ma se oggi per caricare un utente scrivo

IUserServices userServices = ServicesRepository.Get<IUserServices>();
User currentUser = userServices.LoadById(userId);

domani, quando dentro quello IUserServices ci sarà un proxy che si collegherà ad un web service, il mio codice continuerà ad essere perfettamente valido e funzionante. Senza una buona architettura, avrei dovuto realizzare un qualcosa che in seguito avrei dovuto smontare completamente e ricreare da zero.

Ma ancora... il fatto di disaccoppiare gli strati applicativi mi consente di iniettare logica in maniera assolutamente pervasiva: fino ad oggi, leggere una entity da DB comportava la lettura di tutti gli oggetti associati. So che non è bello, è sicuramente uno spreco di risorse leggere informazioni che probabilmente non saranno mai utilizzate. Ma sono convinto che, dal momento in cui si decide di utilizzare un domain model, bisogna *garantirne* la navigabilità: lo sviluppatore, dopo aver caricato l'oggetto User, deve poterne esplorare le dipendenze quando e come vuole. Ma allora? siamo alle solite... una buona architettura mi ha consentito, con un pizzico di AOP, di implementare un LazyLoad che fa perfettamente al nostro caso e che, meraviglia delle meraviglie, fa il paio con l'inversion of control del paragrafo sopra, funzionando senza incertezze sia con lo strato di servizi "in presa diretta" che con nello scenario distribuito che oggi non c'è ma che domani si dovrà necessariamente realizzare (perché è da specifiche). Prossimamente, riuscirò ad introdurre un sistema di log automatico, quantomeno per chiamate ai servizi e errori, e una cache.

Seconda conclusione: l'uso di IoC, DI e AOP ci consente di impostare il lavoro di progettazione e sviluppo su "ciò che sappiamo che un giorno ci sarà", senza badare a quel poco che c'è oggi. Le funzionalità aggiuntive potranno essere realizzate in maniera del tutto indipendente, man mano che si libereranno risorse, e poi introdotte a costo quasi nullo all'interno di quanto già esistente.

Ecco perché, da un paio d'anni a questa parte, la mia passione per questi argomenti è andata via via crescendo e perché sono assolutamente convinto, a dispetto di ciò che molti possono pensare, che una buona ingegnerizzazione del software consente di risparmiare *DA SUBITO* (e non dalla fantomatica versione 2.0 che probabilmente non vedrà mai la luce) tempo, fatica e risorse umane, producendo un risultato qualitativamente con pochi eguali.

Technorati tags: Architettura

Architecture Journal e le applicazioni modulari

Marco De Sanctis — Mon, 29 Jan 2007 12:40:00 GMT

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 :-)

Stasera la chat sugli ORM

Marco De Sanctis — Mon, 22 Jan 2007 12:58:00 GMT

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.

NHibernate e lo special case

Marco De Sanctis — Mon, 20 Nov 2006 01:04:00 GMT

Come fare per utilizzare il pattern SpecialCase con NHibernate?

C.p.l.

Un articolo da incorniciare...

Marco De Sanctis — Fri, 10 Nov 2006 22:22:00 GMT

...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.

Bell'articolo su Model View Presenter

Marco De Sanctis — Fri, 04 Aug 2006 22:47:00 GMT

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 trovare a questo link.

Ah, dimenticavo, la ciliegina sulla torta è che l'esempio proposto è tutto sviluppato in TDD.

Se vi capita, dateci un'occhiata.