ADO.NET: Абстрактное vs Конкретное или "MS - почему?!"

К величайшему своему стыду всегда думал, что MS специально сделал классы ADO.NET для SQL Server и для OLE DB несовместимыми друг с другом. Только сегодня понял, что неправ.

А знаете почему? Потому что во всех примерах, по всему MSDN, во всех книжках код, работающий с ADO.NET пишется вот так:

SqlConnection connection = new SqlConnection(...)
SqlCommand command = connection.GetCommand(...)
SqlDataReader reader = command.ExecuteReader(...)
...

На самом деле, и Sql*-классы, и OleDb* классы совершенно логично наследуют абстрактную модель работы с данными, описанную в System.Data.Common. Это пространство имен предлагает семантику работы с данными через классы DbConnection, DbCommand и т.п.

И по всем правилам объектно-ориентированного дизайна код следует писать вот так:

DbConnection connection = new SqlConnection(...)
DbCommand command = connection.GetCommand(...)
DbDataReader reader = command.ExecuteReader(...)

Тогда программист может при необходимости изменить одну строчку, и перейти к примеру с SQLServer на MySQL (в теории, конечно. На практике все равно весь SQL надо будет переписать. Но тем не менее :-)

На практике - все пишут по примерам. Поиск на Google Code Search по C# коду дает :

• SqlDataReader - 16 000 вхождений
  
• OleDbDataReader - 2 000 вхождений
• DbDataReader - 2 000 вхождений

То есть, грубо говоря, на каждого человека, который пишет обрашение к базе при помощи абстрактных классов, находится 8 (sic!) SqlServer-ных программистов, которые пишут обращение к БД посредством конкретных классов, не думая о возможной унификации кода и забывая, что существует более, чем один движок SQL.

Конспирологическая моя часть немедленно видит сдесь заговор со стороны софтверного гиганта с целью устроить всемирный vendor lock-in и ухудшить переносимость DBшного кода, писанного на дотнете.

Иначе как объяснить?