[SQL, C#] Več kot en data provider

Torej, če želim v aplikaciji omogočiti uporabo več data providerjev (npr. MySQL, Oracle, SqlServer, SqlCE...)
mi za to .NET brez problema omogoča ustvarjanje abstraktnega objekta (IDbConnection, IDbCommand...) in nato konkreten object, ki je odvisen od izbire data providerja. OK.
Kako pa je potem z komandami, nima vsak provider malce drugačen SQL? Brskal sem že po internetu pa na najdem dovolj podatkov v zvezi s tem. Dvomim, da moram za vsakega providerja pisati posebej komande in jih nato glede na izbiro vstavljati v Command. S tem bi bilo preveč 'klobasanja'.
Trenutni query-ji recimo, ki so napisani za SQL Server, ne bodo delovali na Oracle bazi...

Dobi si nek ORM za .NET, ta za vse to poskrbi sam. Ti moraš samo priskrbeti povezave do baze (konfiguracija) in napisati objektno kodo za manipulacijo s podatki.

List of object-relational mapping software @ Wikipedia

sej maš entity framework ...

Osebno bi ti tudi priporočal, da si prebereš kaj na temo The Repository Pattern

Link

Context
In many applications, the business logic accesses data from data stores such as databases, SharePoint lists, or Web services. Directly accessing the data can result in the following:
Duplicated code

A higher potential for programming errors
Weak typing of the business data
Difficulty in centralizing data-related policies such as caching
An inability to easily test the business logic in isolation from external dependencies

Objectives

Use the Repository pattern to achieve one or more of the following objectives:
You want to maximize the amount of code that can be tested with automation and to isolate the data layer to support unit testing.
You access the data source from many locations and want to apply centrally managed, consistent access rules and logic.
You want to implement and centralize a caching strategy for the data source.
You want to improve the code's maintainability and readability by separating business logic from data or service access logic.
You want to use business entities that are strongly typed so that you can identify problems at compile time instead of at run time.
You want to associate a behavior with the related data. For example, you want to calculate fields or enforce complex relationships or business rules between the data elements within an entity.
You want to apply a domain model to simplify complex business logic.