intendo dire: ti fai il Domain Model come ti pare (es: te lo scrivi a manina) e poi realizzi un EDMX che contiene il mapping, avendo cura di far coincidere i nomi di classi e proprietà del tuo DM con quelli delle entità definite nell'EDMX. Ho *appena* fatto un commit di NSK che mostra questa "tecnica": prova a dargli una occhiata e se hai bisogno fai un fischio
Riprendo l'argomento perchè sto miseramente pensando di abbandonare EF4 che conosco appena.Questo perchè ho scoperto (o credo di avere scoperto) che:-Non supporta ancora il mapping di tipi Enum.-Non è possibile utilizzare più di un EDMX (quindi mi resta difficile pensare ad un uso in una applicazione modulare)-Non ho approfondito ma temo da quello che ho letto che potrei avere difficoltà utilizzando più di un DB (anche con gerarchia proveniente dal medesimo db)Quindi tornando a NHibernate aspettando al varco la V.3 potrei:-Implementare un mio Query model come c'era prima in NSK (ma se è stato abbandonato ci sarà un motivo)-Usare NH con il suo provider di Linq e gestire come casi speciali i singoli problemi (magari arrivando a scrivermi a mano il caro SQL) .
per punti:
Non so se sono in grado di parlare solo in lingua DDD casomai provo a spiegarmi "a gesti":-)
>parliamo in "lingua DDD": se per "modularità" [cut]Bounded context si direi di si per quel poco che ricordo/capisco di questo pattern.Vorrei strutturare i vari layer (penserò dopo alla UI con prism) in modo che sia composta da "enne" moduli (es.:base,contabilita,crm,ecc...) ognuno dovrebbe vivere di vita propria. Ogni modulo avrà il suo assembly per ogni layer quindi volevo avere nel DAL di ogni modulo solo mapping (repository,ecc) del modulo corrente.Es.: modulo base con il suo EDMX che mappa solo le entity del modulo base, il modulo CRM con il suo EDMX e così via..Poi al caricamento volevo caricare i datacontext dei vari moduli, ancora non so come ma l'idea era questa.> ...allora puoi (anche se è uno sbattimento) replicare in EDMX differenti la stessa quota di dominio ...Quindi...avere in ogni modulo l'EDMX che mappa non solo le entità del modulo corrente ma anche quelle "condivise" con altri moduli?Es.:Se ho Party in un ipotetico modulo Core e Customer in un ipotetico modulo B2B l'EDMX del modulo B2B dovrà mappare sia Party che Customer,mentre l'EDMX di Core mappera solo Part, giusto? Qesto posso evitarlo se uso la CTP e mapping code only?>Il tutto aspettando che il feature pack (che permette il mapping fluent/code only) arrivi in GA/RTM/RTW ...Mi sconsigli l'uso della CTP4 (uscita da 2 giorni) per eventuali problemi che potrei avere con refactoring cambio di namespace ecc... o perchè la versione finale avrà anche un designer che mi eviterà il lavoro di mapping via code only (che non gradisco molto). Se alla fine si tratta sempre di scrivere il mapping a mano via code only meglio cominciare subito perchè non riesco a digerire la logica (ridondante) dell'EDMX.>mi spieghi meglio cosa intendi con "usare più di un db (anche con gerarchia proveniente dallo stesso db"? Penso ad una soluzione, per esempio, multi-azienda. Dove ho un db per i dati condivisi da tutte le aziende (es.users,configuration,ecc...) ed uno per ogni azienda con i propri dati (customer,supplier,ecc...).In questa realtà dovrei usare due db diversi contemporaneamente (quello "globale" e quello dell'azienda corrente). In caso di necessità, per evitare problemi, potevo cercare di mantenere separati i tipi di entità provenienti da un DB da quelli provenienti dall'altro. Cercando cioè di evitare situazioni tipo : Customer.Owner dove "Owner" è di tipo user. Solo che anche a scriverlo mi spavento perché non so come sia possibile anche solo per il semplice esempio che ho appena riportato. ...E qui credo che sia una connessione alla mia ignoranza su "Bounded context".
Grazie,ciao
prova a dare una occhiata ad Agorà, dovrebbe fare al caso tuo. Uno Shared Kernel condiviso (nel caso specifico, party pattern e User) e differenti Bounded Context, ognuno dei quali *include* lo shared kernel. Per ogni bounded context hai un EDMX che *deve* mappare anche il kernel.
In quanto al feature pack, semplicemente:
E venendo al "multi db", beh... AFAIK *nessun* O/RM supporta out of the box uno scenario del genere, limitandosi alla equazione "1 dominio = 1 database": per supportare questo scenario (e qualche altro requisito) in passato ho dovuto scrivere un O/RM intero, e francamente me lo sarei evitato. Al limite, se puoi "accontentarti" di supportare lo scenario "1 bounded context = 1 db", potresti condividere lo *schema* del kernel, ma per i dati non saprei consigliarti una soluzione "facile"
Ok, grazie per le infomazion. Continuo a guardarmi Agorà.>...limitandosi alla equazione "1 dominio = 1 database": ..Ma allora (rischiando di andare un po' OT) come si dovrebbe affrontare l'argomento multi-azienda. Io ho visto più soluzioni adottate anche da sistemi di terze parti ma quella di utilizzare più db mi sembrava la più "pulita".Perchè è vero "1 bounded context = 1 db" pero è vero che i customer dell'azienda Mario Rossi non sono quelli dell'azzienda GiuseppeVerdi anche se l'architettura del dominio è la stessa. Poi però ci saranno dei dati che dovrenno essere condivisi e qui arriva il problema del doppio db.Certo si potrebbe replicare i dati comuni su tutti i db e lavorare su db per volta ma mi sembra meno pulita.
hai pensato ad un db "multi tenancy"?
Mmm...no ma per mie lacune. Anche se vedo che l'uso di più database è comunque considerato una applicazione multi tenant.http://msdn.microsoft.com/it-it/library/aa479086.aspxA proposito dell'articolo io ho avuto a che fare con applicativi di grosse aziende che usavano una l'approccio 1 ed una l'approccio 3. Quest'ultimo non mi ha mai convinto dal punto di vista dell'architettura del dominio. Un campo su ogni tabella per distinguere il tenant / azienda ?! :-(( mmm non mi piace anche se facilita la vita in "certe" occasioni.
Cmq non vorrei complicarmi lo scenario. Se non dovessi riuscire ad usare i 2 db optero per la replica dei dati, forse...per ora non sono sicuro di niente.Perchè in fondo i dati condivisi non dovrebbero essere molti. Esempio:GlobalDB contiene UserAccount e configurazioni "aziendali" dei vari DB gestiti dalla applicazione.I dati come UserAccount (e altri se ce ne saranno) verranno replicati sui db aziendali.Il login "lavorerà" sul GlobalDB qui verrà selezionata l'azienda in uso recuperando la connessione relativa all'azienda (memorizzata su GlobalDB) i datacontext saranno caricati sulla connessione dell'azienda corrente e lavorerò quindi su un unico DB.Faccio un salto sul discorso precedente a proposito di Bounded Context e EDMX,CodeOnly ecc...A tal proposito il mapping CodeOnly ha le stesse limitazioni,se non erro, quindi non dovrebbe darmi niente di più (tolta la maggiore pulizia)rispetto a un EDMX. Quindi... mha! i dubbi aumentano.