Mi riferisco al post di Diego sui tool di generazione di entities a partire dallo schema del database.
Ma siamo veramente sicuri che generare entities partendo dalle tabelle del db abbia senso?
In OOP un object model è un modello di un problema reale e il db è un modo molto conveniente per gestire la persistenza. Il db è bravo a cercare, ordinare, mantenere integro, gestire la concorrenza e la transazionalità delle modifiche, etc. ma il resto è ben altra cosa.
Se per molti (semplici) problemi entities e tabelle del db possono coincidere, a mio avviso non è vero da un punto di vista generale.
Voglio dire che i dati su db necessitano di essere organizzati in righe, colonne e relazioni perché questo è il sistema più efficiente che oggi abbiamo. Ma non credo che la costruzione di entities a partire da una tabella bidimensionale possa essere esaustiva per la costruzione di un modello.
I modelli infatti per loro natura non possono essere righe e colonne, tantomeno alberi ma a tutti gli effetti sono grafi complessi. Guardiamo l'object model dell'XML oppure del DHTML o ancora di Office ma potremo continuare la lista con quello di Visual Studio e così via.
Un modello deve essere agnosta e non sapere quale sia la forma della sua persistenza. Il primo motivo è che la persistenza non è necessariamente solo una. Con remoting o i web services devo serializzare l'entity; con un database devo mappare lo stato dell'oggetto sulle tabelle del db; con workflow foundation l'oggetto viene persistito ancora diversamente.
Inoltre l'oggetto può anche avere uno stato in memoria che sia radicalmente nella forma e nell'aspetto a ciò che deve essere persistito. Basti pensare ai dati che devono essere criptati, alla forma compatta che il dato può avere in memoria (bit flag in memoria versus id di una tabella di lookup sul database) etc.
Poi la persistenza tra layer dell'applicazione è ancora differente: il fx 2.0 ci impone di segnare con [Serializable] (o ISerializable o ancora IXmlSerializable) le nostre entities. Con il fx 3.0 possiamo usare la peristenza XAML che è decisamente più bella a vedersi grazie anche alle markup extensions. Un domani cambierà ancora.
Un altro aspetto importante è che posso avere differenti applicazioni che si "cibano" dello stesso database. Le applicazioni possono avere bisogno di oggetti molto differenti perché il problema che devono risolvere è differente.
A problema reale differente consegue un modello differente. E quindi la rappresentazione dell'oggetto customer può essere diverso da applicazione ad applicazione anche se condividono lo stesso database.
La parola d'ordine è encapsulation e secondo me un mapping diretto tra tabelle ed entities è spesso un errore di disegno che può funzionare in quanto caso particolare della soluzione ideale.