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
Post a Comment