Home/ Questions/Q 4337374
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T10:56:08+00:00

(continuation of my question here , but thought it was different enough to start

  • 0

(continuation of my question here, but thought it was different enough to start a new thread)

I want to write an application that will allow the eventual customers to use their preferred DBMS (SQLServer, Oracle, etc) for the backend.

I could have the main app call a “Factory” object, located in a separate assembly, that will return a DBMS-specific object that implements a common interface containing all the calls required for DB access. However, this means having the compiled code for all possible DBMS systems deployed with every installation. The factory just chooses the configured assembly.

Could someone comment on this alternative method? : I could create separate assemblies for each DBMS that all use the same namespace e.g. MyDBMS, and implement the same interface. Upon installation, we’d only deploy the assembly for the customer’s chosen DBMS. By changing the build configuration so that the assemblies all get the same name, COM ID, etc. then the main app wouldn’t know the difference. I’ve tested this and it seems to work very well.

Just wondering about the pros/cons of this? The main benefit is that we could supply additional/updated DBMS DLLs without any other redeployment.

Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Ideally, and I suggested it in passing in your previous thread, go for something like nHibernate, an ORM tool. In most situations where the database design does not deviate from the norm too much, this will work fine. On some large-scale applications, basically ones with performance improvements in things like stored procedures, ORM tools will start to impose limitations.

    You could look the other way and say that I support multiple databases by only using behaviour common across them all.

    ADO.NET provides a series of interfaces that most major providers use: IDbCommand, IDbConnection, IDbTransaction. The downside here is you usually cannot take advantage of provider-specific functionality or improvements.

    The Data Access Application Block in Enterprise Library does this. You could go this route, and if you encounter the need to have something specific, you could then change the EntLib code to support your application’s specific requirement.

    This way, you get the bulk of the logic done for you. If you then hit problems (you might not) you then have access to the source code in order to address it.

    • 0