database - what is the best approach to make an application to work with multiple ado.net providers? -


we develop set of industrial applications use sql server.

as demand expands, customers want use our applications own rdbms such oracle, mysql , others.

currently, applications uses oledb provider, , other uses native sqlserver various reasons, including programming experience , religion.

we seek unified approach. project manager prefers oledb because "it works everything." personally, hate because how queries parameters handled...

i have 2 solutions in mind :

the first use sqloledb keeping existing code , adapt each sql statement in case of incompatibility using branch instructions. go quickly, sql not differ , please project manager. however, might turn code spaghetti.

the second use native ado.net provider each rdbms, , develop library of data access each. each library might contain common part avoid code duplication. of course take time, lead clean architecture , optimal performances.

it's client server applications. parts of our database dynamically generated, , there lot of dynamic queries. that's why using orm not possible.

how try achieve same objective?

i 1 of 2 things:

  • use common features between them all, in code mean using idbconnection etc.
  • in app, create set of interfaces onto dal , have dal implementation each supported database.

if can away it, go lowest-common-denominator route. however, may sound need take advantage of database-specific features. if so, best route cleanly in code talk set of interfaces instead of specific dal.

just make sure interfaces enough defined reduce changes later on , offer enough openings support necessary databases.

it case of having factory provide concrete implementation given interface.


Comments

Popular posts from this blog

c# - How to set Z index when using WPF DrawingContext? -

razor - Is this a bug in WebMatrix PageData? -

visual c++ - Using relative values in array sorting ( asm ) -