Prendendo spunto dal mio post precedente e dai relativi commenti, riprendo il discorso "caldo" relativo alla scelta della migliore architettura. Meglio entities o datasets?

In generale, la scelta di stratificare le applicazioni scomponendole in sottoparti deriva dalla necessità di gestire la complessità che è prerogativa dei progetti di sviluppo software, soprattutto se le applicazioni che sono oggetto dei progetti sono di tipo enterprise. La possibilità di ottenere questa scomposizione con diversi tipi di "elementi" permette di identificare diverse scelte architetturali a cui sono di fatto associati altrettanti pattern architetturali.

Se per esempio le unità di scomposizione sono rappresentate da procedure e/o funzioni come nel caso della programmazione procedurale o modulare, la suddivisione avviene per blocchi funzionali. Ogni metodo racchiude tutto quanto è necessario per ottenere una determinata funzionalità applicativa, con una bassa specializzazione logica e una forte frammentazione, ma senza avere una alta complessità. La possibilità di scrivere codice ridondante in questo caso è elevata.

Se invece la scomposizione si basa su layer a cui corrispondono degli insiemi di classi, la complessità necessariamente aumenta. La suddivisione si ottiene tramite la definizione di oggetti ad alta specializzazione, legati ad un ambito specifico.

Maggiore è in genere la specializzazione che si attribuisce alle unità di scomposizione, maggiore è il grado di complessità della struttura ad oggetti che si va a creare. Contemporaneamente maggiore specializzazione comporta un crescente grado di flessibilità.

Quindi, se da una parte applicare i pattern Domain Model e Data Mapper (per rappresentare i layer canonici BLL e DAL usando le entities) porta a scrivere molto codice in più rispetto ad altri approcci, dall'altra il vantaggio si ha in termini di riusabilità e manutenibilità. La scelta è quella di lavorare un po' di più prima per fare sonni tranquilli dopo (almeno in teoria)!

Questo non vuol dire che usare i DataSet scegliendo un approccio basato su Table Model sia una scelta sempre sbagliata... Per applicazioni semplici magari è l'approccio più giusto. Si tratta di trovare la giusta misura! Come nell'ambito di altri settori ingegneristici quali quello edilizio, la scelta della giusta misura significa un dimensionamento mirato agli scopi. Come non ha senso fare dei pilastri larghi dieci metri per sostenere una villetta a schiera, allo stesso modo non ha senso pensare ad una architettura troppo complicata per un semplice sito che pubblica due news in croce.

Quindi per concludere l'argomento, è mia opinione che ogni scelta architetturale deve essere fatta in modo mirato in base alla dimensione dell'applicazione. Ha senso investire in termini di complessità se il gioco vale la candela. Il buon senso e l'esperienza in questo caso permettono di fare di volta in volta la scelta giusta...