1

One of the requirements of the ASP.NET application I'm developing is to be database-agnostic; that is, to be able to talk to an amount of database engines without having to make significant changes to the code. I already know that the first part of the solution involves abstracting the DAL (data access layer) behind an interface, and that makes it possible to replace the DAL without code changes, but the problem I'm facing is how to implement the DAL.

Research has been very inconclusive in that regard, but it tells me I have 2 choices:

  • Using an ORM (like Entity Framework or Dapper)
  • Writing it completely in ADO.NET

Entity Framework is easy, but it seems that once I generate the model, EF will not allow me to change the DB engine it targets. OTOH, writing many DALs in ADO.NET (one for each target engine) allows me that flexibility, but I'm stuck with writing everything from scratch.

So I have the following questions:

  1. Is there a way to make EF talk to different DB engines on runtime?
  2. If not, is there any mature, stable ORM that supports multiple DB engines on the fly?

Thanks in advance.

Léster
  • 1,177
  • 1
  • 17
  • 39

1 Answers1

0

It looks like it's possible with entity framework - Same EDMX file for different Providers

However, to me it sounds like a recipe for disaster. I would write it myself using ANSI SQL, making sure that my tables, columns and data types across all DBs matched and had the same behaviour - as well as foreign keys, automatic key generation etc. Then test everything and cross my fingers.

Community
  • 1
  • 1
Rocklan
  • 7,888
  • 3
  • 34
  • 49
  • So I'm pretty much stuck with ADO.NET and and ANSI SQL? Luckily for me, I don't need to use many special features (at most, views and stored procedures which I can abstract behind the DAL in any case). The only thing I'm gonna miss is EF's support for FKs. – Léster Dec 09 '16 at 03:48