Matteo Migliore - Solution architect - Corsi .NET - Consulente .NET

Matteo, farsi generare il modello del tuo database partendo dal domain model è quanto di più sbagliato si possa fare.
In questo modo ottieni un database che non è nient'altro che un file di testo più scomodo da usare, visto che il modello dei dati non rappresenta realmente i dati con cui tratti nella realtà (hai infatti tabelle come UniqueObject e le varie *Reference che dubito abbiano un significato nel mondo reale).
Cosa significa questo in pratica? Che il tuo database non implementa i constraint necessari per mantere i dati integri ed inoltre rende più difficile la consultazione e l'accesso da parte di altre applicazioni.
Ovviamente di questo non ti accorgerai subito, perchè finche i dati sono pochi tutti i database vanno bene, ma te ne accorgerai quando sara troppo tardi, ossia quando il tuo database sarà in uso e pieno di dati e non potrai più metterci mano.
Meglio quindi iniziare da subito a modellare correttamente il database, cosi potrai usare l'ORM che preferisci per fare il mapping (che è quello che un ORM si deve limitare a fare) e non per costruire il database dalle classi, cosi come sarebbe stato sbagliato (ma in misura minore) creare le classi dalle tabelle.
Ricorda che il database è il posto dove verrano memorizzati i dati per il resto della loro vita. Un errore di progettazione iniziale del database si riperquote sulla tua applicazione per sempre.

Ciao Davide,

ciò che (intepreto) Matteo ha fatto è semplicemente far generare a NH lo script SQL per la creazione dello schema in base a quanto specificato nel mapping.

Concettualmente non ci vedo nulla di male, per il semplice fatto che non è NH ad inventarsi lo schema, che invece è *assolutamente progettato* da chi realizza il mapping. Il problema, semmai, è che si tratta di un approccio utilizzabile solo in casi estremamente semplici, perché quando le tabelle diventano dell'ordine delle centinaia, la vedo dura ad andare avanti senza un apposito strumento di progettazione (che so... Erwin, tanto per citarne uno).

Che poi in questo caso specifico Matteo abbia deciso di mappare *tutta la gerarchia* di classi, tra l'altro in table-per-subclass, trovandosi poi quello schema "strano", è un altro paio di maniche. Ma ribadisco: è una scelta esplicita di Matteo, che magari io e te non condividiamo, ma non è nulla di autogenerato da un qualche tool.

@Marco
Ciò che scrivi nel tuo commento è perfettamente sensato e condivisible. Infatti il mio commento nasce più che altro dalla lettura dello schema del database ottenuto imvho in un modo che è troppo legato all'OOD, che come si sa mal si conciglia con l'approcio ER (e viceversa). Un file di mapping fatto bene sicuramente aiuta ad avere un modello ER migliore ma si parte sempre dal concetto che si sta prima disegnado il Domain Model e poi il modello di database. In mia opinione questo non è mai accettabile (se non per progetti molto piccoli e/o amatoriali) cosi come non sarebbe accettabile avere la classi generate direttamente dal database. I due modelli OO e ER sono diversi, punto. Qualsiasi tool che automatizzi il passaggio da uno dei due andando semplicemente a replicare ciò che stato fatto in un modello su altro deve essere esplicitamente marcato con la dicitura "Da usare solo se stata sapendo ESATTAMENTE a cosa andate incontro" e non visto come uno strumento per essere più produttivi o più efficienti, potendo fare solo uno dei due modelli per ottenere cosi l'altro gratis. Perchè questo, lo sappiamno, lo si paga (tanto) sul medio e lungo periodo, andando incontro - non di rado - a problemi semplicmente insormontabili.
Quando si parla di modelli si parla implicitamente di architettura (dei dati o dell'applicazione) e su questo cose è sempre bene andarci cauti visto che decretano il successo o l'insuccesso di un progetto. Un progetto fallito - attenzione - non è solo un progetto non terminato. E' un progetto che a lungo andare costa più in manutenzione e supporto che di quanto dovrebbe far risparmiare. In pratica fa spedere continuamente soldi alla società che lo usa, ad esempio perchè non protegge adeguatamente i dati che diventano cosi logicamente incosistenti oppure perchè l'applicazione non ha un'architettura sufficientemente flessibile. Credo questi siano in particolare i motivi che contribuiscano molto a far si che in Italia l'IT sia visto ancora soprattuto come un costo e non come una risorsa.
Meglio sempre quindi rimarcare la cosa. Poi ovviamente ognuno sa su che ti di progetto sta lavorando e deciderà di conseguenza. Ma almente è avvisato :-)

@Matteo
"Iniziare a modellare il DB e poi le classi?"
Non mi pare di averlo mai detto.

"a tua posizione è completamente diversa, tant'è che non sostieni nemmeno il Domain Driven Design. "
Matteo non dire stupidate. Programmo ad oggetti da anni e non mi sognerei mai di sostere che l'approcio alla programmazione OO attraverso la definizione di un Domain Model sia sbagliata. Ma questo non vuol dire che sia quella giusta anche per i DB.
Il fatto che difenda strenuamente il modello relazione non significa che non apprezzi il modello ad oggetti (visto che tra l'altro sono molto ma molto più simili di quanto molti pensino. Sto parlando del *vero* modello ad oggetti non quello implementato negli attuali RDBMS)
"non c'è alcuna differenza tra i file di mapping e un file .sql contentente gli script di creazione."
certo mai infatti io sto parlando del modello (l'architettura!) non dei file creare fisicamente gli oggetti. Di quelli noc c'è nessun problema nel fare creare il db da un tool automatico piuttosto che farlo a mano.
Il problema è COME e PERCHE decidiamo che tabelle creare. Non puoi crearlo utilizzando gli stessi principi che usi per l'OOD cosi come non puoi creare classi utilizzando gli stessi principi che usi per creare un modello di dati relazionale.

Scusa ma quello che usi non mi sembra il tono da usare sul blog altrui. "Non dire stupidate" evitalo, per evitare che cancelli i commenti. Chi dice stupidate, è stupido, ed io non lo sono. Questo *non* uno spazio dove fare polemica. Detto questo, il modello ER è antecedente, e molto più povero del class diagram. Non esiste behavior per una tabella. Ripeto, la scelta di creare una tabella UniqueObjects è dovuta ad implementazioni future (versioning, localizzazione al momento). Comunque aspetta la fine del progetto, e se vorrai partecipare, tanto meglio! :-). Un saluto amichevole.

"il modello ER è antecedente, e molto più povero del class diagram. Non esiste behavior per una tabella. "
Matteo dovresti sapere che il modello relazionale è *ovvio* che rappresenti solamente dati non metodi. Ciò è stato fatto per poter utilizzare solamente una logica dichiarativa per l'implementazione di constraint di validazione delle business rules. In particolare "First order logic": http://en.wikipedia.org/wiki/First-order_logic.

In questo modo in un db relazionale tutto può (dovrebbe) essere definito in modo dichiarativo, permenttendo allo sviluppatore di specifcare COSA vuole ottenere e lasciando il COME all'optimizer (e questa idea è talmente valida che oggi LINQ ti permette di fare la stessa cosa)

Per il resto, ho solo corretto un errore madornale che ha scritto sulla mia persona (che mi ha dato perticolaremente fastidio, visto che se critico o apprezzo un modello lo faccio perchè lo conosco e non per sentito dire).

Non vediamo invettive laddove non ce ne sono :-)

Un saluto amichevole anche da parte mia.

Validation Framework ed Inversion Of Control