Ciao a tutti

In ogni ambito di sviluppo (windows, web, enterprise) esistono pattern più o meno efficienti, ad esempio per un gestionale di piccole dimensioni con target windows sicuramente è una scelta vincente l'uso di dataset, stessa cosa dicesi per applicazioni web di piccole dimensioni scritte nell'ottica di uno sviluppo RAD (rapido). i pattern che sono dietro a queste scelte sono quelli del "table module" (http://martinfowler.com/eaaCatalog/tableModule.html) o dell'"active record" (http://martinfowler.com/eaaCatalog/activeRecord.html).

Diversamente esistono architetture enterprise dove le esigenze di sviluppo rapido vanno a essere sostituite da altri fattori che nell'insieme vanno a misurare la bontà del sistema per intero: tempo di risposta ad una singola azione, carico di lavoro (numero totale di transazioni effettuabili), efficienza per singola CPU, scalabilità verticale e orizzontale, manutenibilità (aggiornabilità dei componenti), espandibilità (con nuovi elementi senza modificare ogni volta tutto), maturità (stabilità) e ripristinabilità (capacità di ritornare su dopo un errore critico), i pattern cambiano e troviamo: "domain model" (http://martinfowler.com/eaaCatalog/domainModel.html) per l'accesso ai dati, o MVP/MVC per la realizzazione delle interfacce e cosa più importante esiste una necessaria layerizzazione del sistema andando a scinderlo in più livelli ognuno dei quali dedicato a un unico compito: interfaccia utente (web, windows o smart), business-logic (transazioni, validazioni e strategie di business), data-access (accesso ai dati), etc, eventualmente aggiungendo ulteriori sottolivelli dove necessario.

I pattern quindi sono uno strumento efficace nello sviluppo di ogni tipo di applicazione, ma si puo anche sbagliare?

Voglio dire, è ovvio che se scrivi una applicazione enterprise in RAD ti va da favola i primi 1 o 2 mesi... ma poi ogni giorno devi sempre più rimodificare lo stesso codice, rifattorizzare e comunque deployare sempre tutto insieme con i suoi relativi problemi, ma oltre la scelta sbagliata c'è anche un altro problema: l'esasperazione.

L'esasperazione è quando ad esempio chiedo ad un collega: mi chiami una SP (stored procedure) che devo fare un test? e lui ansicchè andare in sql management (la console di sql server) e scrivere "exec sp_xxx" e dirmi se ha dato un errore, dopo 2 ore mi risponde: vuoi che indica una riunione per definire la nomenclatura dei DTO (http://martinfowler.com/eaaCatalog/dataTransferObject.html) con cui ti torno il risultato da un servizio che usa NHibernate (domain model) per chiamare la stored? :|

Voglio dire, un pattern è uno strumento necessario alla vita di uno sviluppatore professionista che vuole scrivere o partecipare alla scrittura, alla analisi o alla definizione di una architettura software di una certa entità. Ma è sempre e solo uno strumento, ed in ogni caso, una massima importante da capire è che ogni pattern puo essere giusto o sbagliato ma l'unico modo per valutarlo è TESTARLO. Basta leggere più su, ho detto senza mezzi termini che "active record" non è enterprise.. ma non è vero, puo esserlo. Puo esserlo nel momento in cui crea benefici alla nostra applicazione ed è compatibile con tutti quei requisiti non funzionali che ho scritto un pò più su... Solo un load-test (test di carico) puo dirci se un pattern ci da veri benifici prestazionali, così come solo noi possiamo dire se un pattern assolve ai nostri requisiti e quindi è utilizzabile in un determinato ambiente. Ed infine non dimentichiamoci che un pattern va sempre adattato al sistema in cui si usa, spesso l'errore più grande è li: un software non è una sommatoria di patter eterogenea (tipo lo spaghetti-pattern) ma deve essere un insieme di componenti razionalmente collegati con i pattern giusti ed adattati allo scopo (chiamiamolo lasagna-pattern).

Ovviamente il tempo da ragione ad alcune scelte, ma questa è solo statistica, nulla di più.

Alla prossima