Originariamente inviato da rsdpzed
scusate la pignoleria ma non confondiamo le acque (avevo tralasciato gli orm apposta dal mio reply)
La pignoleria va benissimo, ma qui nessuno ha "confuso le acque": si è risposto alla domanda.

Originariamente inviato da rsdpzed
Ef è un ORM che fa da ponte tra il db e il modello a oggetti (piu altre cose carine come le join trasparenti, il pattern transaction, la gestione della concorrenza...). MA il file edmx del modello di ef è strettamente legato al rdbms specifico. Non basta cambiare la stringa di connessione. Infatti ogni compagnia a sua discrezione e con tempi di aggiornamento variabili, si occupa di fornire il plugin per poter utilizzare EF (e altre tecnologie) con il proprio rdbms.
Ok, e quindi?

Il fatto di poter sostituire il "mapping" tra i propri oggetti e il layer di persistenza è uno strumento che consente di rimanere indipendenti dallo storage finale, esattamente come richiesto. Poi non è ovviamente obbligatorio usare un ORM: ci si può costruire un layer personalizzato così come hai descritto tu.

Il vantaggio offerto da EF - tramite un file di configurazione (EDMX) e un sistema di classi già disponibili - è lo stesso che proponi tu con la tua struttura a interfacce.

Originariamente inviato da rsdpzed
Detto questo, per rispondere alla domanda del topic (applicazione che supporta piu rdbms), nel caso di ef la situazione si complica perche EF oltre all'accesso ai dati ingloba anche il modello (quello che nel mio esempio "rustico" ho chiamato progetto entità separandolo dal dal) per cui l'unico modo per supportare piu rdbms in modo trasparente è quello di switchare le dll (una per ogni implementazione) a runtime con reflection (sempre late binding ma piu "scomodo"), o piu facilmente una tantum in fase di installazione (l'installer sceglie la dll), oppure usare strumenti come mef (mai usati ma dovrebbero servire allo scopo).
Ripeto la domanda di prima: e allora?

E' un tool che, come qualsiasi altro strumento, va approfondito per capirne le potenzialità, ma tecnicamente fa esattamente ciò che è stato richiesto, e assolve allo stesso compito che hai indicato tu con le classi che andresti a scrivere manualmente.

Originariamente inviato da rsdpzed
Personalmente sono soluzioni che non ho mai provato per cui non saprei dire quale sia piu " facile o difficile" rispetto alle altre.
Questo dipende dal tipo di applicazione. Se si tratta di un requisito necessario per un'applicazione che scrive su una sola tabella, allora non mi pare il caso di scomodare un ORM per questo; se l'applicazione è un po' più complessa e di respiro più ampio, francamente non avrei dubbi nell'accantonare la realizzazione a mano di un "data layer" personalizzato al posto di scegliere una soluzione collaudata e documentata che fa già egregiamente quello che mi serve. Ma questo è solo un parere personale.