Avevo già scritto tempo fa riguardo il mio set di classi che
avevo sviluppato appositamente per gestire progetti asp.net basati su
architettura multi-layer.
L'obiettivo di tale architettura è di permettere un disaccoppiamento tra i
vari strati lasciando a ciascuno l'onere delle proprie responsabilità
funzionali.Questo comporta una seri di vantaggi, tra cui la possibilità di
delegare a persone diverse la gestione dei vari strati applicativi piuttosto che
garantire una maggiore sicurezza e affidabilità di intervento durante
processi di manutenzione, correzione e aggiornamenti sul progetto.
Da qualche mese ho cominciato il processo di adattamento, e più precisamente
di refactoring, di tale framework verso la versione 2.0 di .NET.
Quindi largo uso di partial classes e di generics, in particolare.
A parte le differenze di implementazione dovute dall'uso di C# 2.0, ho
introdotto la possibilità di gestire delle custom entities un po
particolari.
Infatti capita spesso in applicazioni di front-end di dover visualizzare
griglie di dati che poco hanno a che fare con una precisa entità.Per esempio
l'elenco prodotti di un catalogo di una soluzione di eprocurement potrebbe voler
visualizzare solo il codice ed il nome del prodotto, mentre nella griglia
servirebbero altri dati quali attributi e prezzo.
La soluzione
object-oriented ideale proporrebbe di avere nella classe prodotti il riferimento
alle altre entità o collection di entità che sono in relazione con la classe
stessa.
Questo è vero, ma per motivi quali una minor complessità di
implementazione ed esecuzione e di performance, preferisco mappare all'interno
di una classe solo le entità che corrispondono alle foreign key della tabella
che mappa la classe stessa.
Motivo per cui, la soluzione che ho adottato è stato quella di gestire un
secondo tipo di entities, che ho chiamto views, che in pratica non sono altro
che il mapping diretto con una vista di Sql Server(nel mio caso sto usando Sql
Server come database).
Dal punto di vista degli strati applicativi non cambia nulla in quanto ci si
troverà sempre a dover pensare in base al dominio.Non usero
List<Products>, ma userò List<AllProductsApproved> per esempio.
Con il vantaggio che ci guadagnerò in performance in quanto il processo di
lettura e riempimento di tale collection sarà più snello in quanto ogni campo
della vista corrisponderà direttamente ad una proprietà "semplice" (no altre
custom entities) sulla classe, senza dimenticare che saranno lette le sole
proprietà(colonne) che servono.
Ovviamente ho sempre con me i template di CodeSmith che mi generano tutto il
codice che serve nei vari livelli(DAL, BLL e Domain).
Per i puristi forse non la soluzione migliore, ma questa è secondo me una
soluzione che rappresenta un giusto compromesso.