Compositum5копеекВсем спасибо, почитал, подумал поэкспериментировал.
универсальный класс в моем случае порождает слишком много всяких если.
под каждую субд буду реализовывать свой класс обращения к данным.
В конце концов разные типы коннекшнов и т.д. для того и создавали.
Если бы все было так гладко, сделали бы один универсальный класс.
Всем спасибо...
плохо подумали. для того и реализован единый интерфейс для всех классов - чтобы по одному образцу работать со всеми. дело ваше (пожимает плечами...)

чем Ваш код

отличается от моего изначального

Плюсы в чем ?
В вашем решении пока я вижу только лишние телодвижения и в результате те же проблемы: проверка по типу и кастомная логика для каждого типа, ручками.

Compositum5копеек
Плюсы в чем ?
В вашем решении пока я вижу только лишние телодвижения и в результате те же проблемы: проверка по типу и кастомная логика для каждого типа, ручками.
плохо смотрите. вы знакомы с расширяющими методами (судя по вашей реплике - нет). Иначе бы знали, что данный класс добавляет к любому экземпляру класса DbCommandBuilder (или наследуемому от него) новый метод - DbDeriveParameters.Теперь любой экземпляр класса DbCommandBuilder имеет этот метод. Пояснять плюсы не буду, ибо они очевидны.

п.с. не ленитесь читать книжки...

Я со всем этим согласен, но к выводу как раз пришел читая книжки,
Цитирую:
"Например не существует обобщенного способа перехватывать объекты исключений базы данных...."
"... разные поставщики могут подерживать специализированные средства, недоступные для общих базовых классов"

Я не говорю что предложенный вами подход неудачен. В вашем случае его возможно достаточно, в моем случае он может оказаться неоптимален. Причем неоптимален впоследствии.
В данном случае мне важнее возможность как можно более широко использовать возможности предоставляемые каждой СУБД. А универсальный поставщик как раз сужает эти возможности.
Условно говоря я лучше сейчас потрачу время, чем потом окажусь перед проблемой ради которой придется рефакторить пару-тройку-десятку приложений.

В любом случае спасибо за инфо, все это очень помогло.

PC_2


Спасибо, на мой взгляд верное замечание.

CompositumО каком универсальном поставщике идет речь? Ведь мы извлекаем каждый раз конкретного, нужного нам поставщика, просто упаковываем его в родительский класс. Но распаковать-то не проблема. Это в C++ (насколько я знаю) если бы мы упаковали объект дочернего класса в родительский, то все то, что было характерно чисто для дочернего класса - обрубалось, однако в шарпее это ведь не так - мы всегда может затем без каких либо потерь преобразовать в его настоящий тип и использовать его на все 100%.

Поясните пожалуйста.

В данном случае я понял вас так.
Есть некий класс или унаследованный метод - оболочка обрабатывающая запросы к серверу БД.
В него передаем класс DBcommand с заполнеными параметрами и строкой соединения.

В вашем случае имеем внутри этого класса

Я правильно понимаю или нет вашу идею?

В моем случае

в любом случае для каких то операций специфичных для каждого сервера БД нужно проверять тип провайдера и условно обрабатывать его.
В таком контексте не вижу смысла использовать DbProviderFactory. Т.к логика что с ним что без него одинакова, а сложность кода возрастает.
Возможно я чего то не понимаю, поясните.

SQL_Lamer
Ничего нигде вы не сужаете.
Объясню по простому.
У вас есть конкретные классы для работы с разными серверами(с учетом их индивидуальных особенностей).
Фабрика вам дает упакованный объект, в этом конкретном классе вы его распаковываете, и работаете с учетом этих особенностей.

я понимаю что фабрика дает мне объект, я не понимаю смысл писать под фабрику если можно написать new "то что мне нужно" точно так же в зависимости от строки подключения и получить объект заточеный под конкретную СУБД.
Я не отвергаю этого подхода, просто не понимаю зачем лишняя возня с "упаковыванием / распаковыванием" как вы выразились
Был бы смысл если бы все провайдеры были полностью взаимозаменяемы, но этого нет на 100%.

Пока для меня смысл использования фабрики представляется примерно такой же как для того что бы использовать trim строки преобразовать ее сначала в объект а затем обратно в строку.
В чем гибкость не понимаю.

Compositum5копеек,

возможно понимание придет к вам со временем, я устал биться

Если вы не в состоянии объяснить, возможно вы сами не понимаете?

Compositum5копеекCompositum5копеек,

возможно понимание придет к вам со временем, я устал биться

Если вы не в состоянии объяснить, возможно вы сами не понимаете?
именно так, я не понимаю вместе с разработчиками Майкрософта, создавшими класс DbProviderFactopy, и вместе с Дэвидом Сеппой, который в конце своей книги в приложении подробно разъясняет все прелести данного подхода вы обсолютно правы, снимаю шляпу

Ну если у вас самоцель обязательно использовать каждый класс фреймворка, то тогда конечно вы правы .

Ну раз Сеппа разъясняет, вам что стоит повторить то что он говорит?

Пока мое впечатление осталось прежним.
DbProviderFactopy для простеньких приложений , аля select * from employee годится. А когда требуются всякие извраты с БД с уже написанным приложением, лучше использовать свои методы/для каждой БД.
А из книг я использую то что оправданно а не слепо пихаю везде модные новые словечки.
Ни Сеппа ни разработчики microsofta мои проблемы решать потом не будут.