Dataset vs Domain Model: dove pende l'ago della bilancia?
dipende...come
rifletteva giustamente
Marco...
se una persona ha come strumento il framework .NET e basta,
effettivamente tutti gli spunti hanno senso...
ma facciamo un giochino, una piccola aggiunta,
e invece di fare
DomainModel vs
Dataset proviamo a fare
DomainModel & NHibernate vs
Dataset.
Riassumiamo e mettiamo in croce gli spunti di riflessione
Punti a favore del dataset espressi da Marco:
|
Domain Model con NHibernate |
| il dataset essendo basato su un Table Model è direttamente mappato sulla struttura del db, invece con il Domain Model avremmo bisogno di un Data Mapper che non è così facile da implementare |
NHibernate implementa il Data Mapper. :-)
In questo modo con il domain model non mi faccio fuori polimorfismo, ereditarietà e dulcis in fundo ValueObject e Composite, tutte caratteristiche che non ho con i dataset. |
| l'integrazione del DataSet nell'IDE di Visual Studio e la struttura estremamente versatile, permettono di gestire facilmente anche strutture piuttosto complesse, che coinvolgono DataRelation e campi calcolati |
Un campo calcolato nel domain model è semplicemente una property da aggiungere alla classe. |
| il DataSet funziona particolarmente bene con il DataBinding, implementando diverse funzionalità non banali |
Nel fwk 1.1 bastava una collection fatta bene che implementasse le giuste interfaccie, scritta una volta per tutte e riutilizzabile per tutti i progetti.
Si poteva usare la custom collection come fosse un dataset, strongly typed a design time ect..
Nei miei progetti lavoro tranquillamente anche con controlli complessi in databinding complesso bidirezionale, e non ho mai sentito la necessità di un dataset....(meno male!)
Adesso nella 2.0 c'è BindingList<T> che semplifica ancora il lavoro... |
| perché ci si può avvalere di generatori di codice che risparmiano parecchio lavoro (usare questi strumenti per un Domain Model, a mio modo di vedere, è un controsenso allucinante) |
Ovviamente è un controsenso. Non si può partire dal db per generare codice. Ma nel caso uno si volesse fare del male, può cmq farlo anche con il domain model e con i generatori di codice che ci sono in giro gratuiti. Otterrebbe classi di dominio tipo Table Model.
Io lo picchierei con il randello ma questa è un altra storia...:-) |
| perché con l'accoppiata DataSet/DataAdapter ci troviamo gratis anche un bel Unit of Work e un Optimistic Offline Lock per gestire opportunamente le modifiche effettuate in locale. |
Questa è quella che preferisco:
con Nhibernate (nel solo oggetto session) mi trovo implementato:
DataMapper
UnitOfWork
Optimistic Offline Lock
IdentityMap
e forse anche qualcos'altro...adesso non ricordo :-) |
Quindi uno pensa...invece di skillarsi sui ADO.NET disconnesso, mi skillo su NHibernate...:-)
e adesso l'ago della bilancia dove pende? :-P
Ovviamente era (anche) una provocazione...
(fatta da uno che è così tanto "integralista" degli ORM che sta cercando il modo di levare le classi dei dataset dal disco...perchè gli occupano spazio inutile...)
Ciao Marco...Up the irons!