Quindi ipotizzavo di rifare un object model da poter utilizzare nell'applicazione indipendente dai dati.
Sì, fai bene, creati un unico object model che poi andrai a mappare sui due database.
Valuta
Entity Framework 4.1 Code first perché così sei libero di scrivere le tue classi come più ti sembra opportuno, e potrai infine impiegarle in due DbContext diversi allo scopo di persistere le istanze su questo o su quel database.
Il mio problema è come gestire il DAL, cosa mi consigliate Repository
I tuoi repository saranno gli
IDbSet<T> che inserirai come proprietà delle tue implementazioni di DbContext.
Questi ultimi lavoreranno secondo il pattern
Unit of work, monitorando tutte le istanze che avrai aggiunto/modificato/rimosso usando i repository (i già citati IDbSet). Andrai a persistere i cambiamenti invocando il metodo .SaveChanges del DbContext.
Leggi questo articolo di Stefano Mostarda, ti dà delle indicazioni pratiche su come fare il mapping con Entity Framework 4.1 Code First.
http://www.linqitalia.com/articoli/entity-framework/mappare-classi-dominio-code-first-entity-framework.aspxIn particolare, segui a pagina 2 il paragrafo "Personalizzare il mapping one-to-one tra classe e tabella". Facendo l'override di OnModelCreating potrai definire due mapping diversi in ciascuno dei due DbContext, pur riutilizzando le stesse identiche classi dell'object model.
Ora, siccome hai due database di destinazione, e quindi due implementazioni simili di DbContext, ti converrebbe estrarre da loro un'interfaccia comune che descriva tutti gli IDbSet che dovranno trovarsi al loro interno.
A tal proposito, leggi quest'altro articolo.
http://refactorthis.wordpress.com/2011/05/31/mock-faking-dbcontext-in-entity-framework-4-1-with-a-generic-repository/Potrebbe sembrare che, così facendo, si aggiungano inutili livelli di astrazione l'uno sull'altro ma secondo me la tua applicazione ne guadagnerebbe in testabilità e manutenibilità
Per capirci: le varie pagine che contengono i form non dovranno saper nulla del fatto che l'applicazione è regolata da due database. Dovrai relegare questo concetto dentro una classe che sia in grado di lavorare con una lista di DbContext, anzi, di IDbContext, così che un giorno sari libero di eliminare un database o di aggiungerne un altro senza che per questo la tua applicazione smetta di funzionare. Deve poter essere in grado di leggere e scrivere su più fonti, secondo la tua logica di funzionamento.
Astrarre vuol dire modularizzare, ma anche introdurre più parti in movimento nell'applicazione, con conseguente accrescimento di complessità. Purtroppo però non c'è altro modo se vuoi evitare grane in futuro.
ciao,
