Progettazione strati app con NHibernate e il contesto di database cambiando

Question

Sto progettando un'applicazione C #

• Presentazione (sito web + flex apps)
• livello logico Affari (potrebbero essere WCF per attivare piattaforme multi client)
• Data Access Layer (con NHibernate)

Stiamo andando a integrare la nostra soluzione in Environnements di database molti preexistant del cliente e vorremmo usare NHibernate nel DAL .. Il mio collega ha sottolineato che le classi di generazione da DB del cliente (come utente o Immagine) con NHibernate causerebbe il BLL far saltare in faccia ad ogni modifiche DB! Quindi la domanda è: come possiamo evitare che ciò accada? Stiamo pensando di creare oggetti di business e piano di NHibernate si oppone a questi BO (ronzio, fa che li rendono DTOs?) Con automapper e impedire modifiche Dal incidano BLL .. E 'questa la strada da percorrere?

Grazie!

Modifica

Per dare una migliore comprensione di ciò che stiamo cercando di raggiungere, potrebbe essere necessario contesto: Stiamo costruendo una foto memorizzazione / condivisione app in Flex per il front-end e C # sul back-end soprattutto per la nostra azienda, in modo da gestire tutti gli aspetti del codice e DB.

Ma : il prodotto può anche essere acquistato da gradinate, che alla fine hanno già un database con la tabella per l'utente o un tavolo Immagine. Sto pensando qui circa un nuovo prospetto che hanno una tabella Immagine con alcune centinaia di milioni di righe e colonne aggiunta per la nostra logica di business non sta per accadere a causa di una troppo lunga alterazione di tabella.

Anche se sarebbe possibile (tabella utente per esempio può essere modificato a causa di righe minore), ci chiediamo come gestire i cambiamenti di struttura tavolo senza impattare tutti della nostra soluzione ogni volta che dobbiamo integrare in un database tier , da BLL a un'applicazione client in Flex!

Answer 1

nella mia esperienza, gli oggetti di business (AKA Domain Objects) deve essere modellato in OO per rappresentare i vostri entità di business reali e le tabelle in forma normale 3 ° (questo può cambiare a seconda di quale disegno siete dopo velocità vs dimensioni del file)

NHibernate dovrebbe mappare tra il vostro BO e di tabelle, utilizzando i suoi file di mapping.

ora avete casi legittimi:

• È necessario aggiungere / rimuovere una colonna, abbiamo deciso di rimuovere addressline4, questo eco un cambiamento nel vostro Indirizzo Oggetto, questo è bene.
• Si sposta di una colonna in un posto migliore, il nostro oggetto client contiene le note, che è attualmente memorizzati nella tabella Contract_Extra, che sta per essere spostato nella tabella Cliente. spostare la colonna in un posto migliore sarà solo effettuare il file di mapping, in questo caso

Dubito che ci sia un ragionamento coperta, però spero che gli esempi fanno pensi di questo

non ho provato NH attraversato più di Db, anche dovrebbe ogni database dispone di un proprio servizio in cima ?

ecco alcuni link

• Multi Table entités
• PoEAA <- sguardo alla eredità tavolo singolo, eredità tavolo di classe e l'altra

Spero che questo aiuti

Answer 2

Sembra che si vuole progettare il modello di dominio per essere di database agnostico. Anche Sono interessato l'approccio migliore per avere un modello di dominio centrale che può mappare oltre a più modelli di database diversi.

Il modo in cui lei propone, per creare DTO da ogni database utilizzando generatori di codice, potrebbe essere un'opzione. Un'altra potrebbe essere quella di creare mappature NHibernate personalizzato per ogni database preesistente. È ancora essere necessario utilizzare alcuni DTOS per fare alcune delle mappature meno difficile, ma può dare un maggiore controllo.

Questi sono solo alcuni pensieri. Gli utenti più esperti con NHibernate probabilmente avranno una migliore comprensione della situazione.