IdbConnection против SqlConnection

Question

Когда я пишу приложение, я использую интерфейсы System.Data (IDbConnection, IDbCommand, IDataReader, IDbDataParameter и т. Д.). Я делаю это, чтобы уменьшить зависимость от поставщиков. Если только я не делаю простое тестовое приложение, это просто похоже на этическую вещь, когда нужно консультироваться.

Однако, похоже, что весь код, который я вижу, использует классы пространства имен System.Data.SqlClient или классы, специфичные для других поставщиков. В журналах и книгах легко объяснить это влиянием Microsoft и их маркетинговой ориентацией на программирование только против SQLServer. Но он выглядит так, как будто почти весь код .NET, который я вижу, использует специальные классы SQLServer.

Я понимаю, что классы, относящиеся к поставщику, обладают большей функциональностью, например, добавление параметра к объекту SqlCommand - это один из методов, при котором добавление его в IDbCommand вызывает раздражающие строки кода 4+. Но затем снова; написать небольшой вспомогательный класс для этих ограничений довольно просто.

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

Используете ли вы специфичные для поставщика классы данных или интерфейсы?

РЕДАКТИРОВАТЬ: Чтобы обобщить некоторые из ответов ниже, и добавить некоторые мысли, которые я имел, читая их.

Возможные подводные камни в использовании интерфейсов для нейтральности поставщиков:

• Ключевые слова поставщика, встроенные в ваши утверждения SELECT (все мои модули, upd, & del в procs, так что это не проблема)
• Связывание напрямую база данных, вероятно, приведет к проблемы.
• Если только ваша связь инстанцирование централизовано, класс конкретного поставщика потребуется все равно позвони.

Положительные причины использования интерфейсов:

• По моему опыту способность (даже если не осуществлено), чтобы перейти к другой поставщик всегда был ценится заказчиком.
• Использование интерфейсов в повторно используемых библиотеках кода

Answer 1

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

При этом я думаю, что в большинстве случаев вам следует использовать слой, который вы создаете самостоятельно, выше фактического .Net API, так что если вам когда-либо придется менять какие классы вы должны использовать, то это не будет такая большая проблема. Даже если вы остаетесь в той же базе данных, вы никогда не узнаете, когда вам придется переключать доступ к базе данных. Любой, кто перешел с ASP на ASP.Net (ADODB против ADO.Net), может сказать вам, насколько это больно.

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

Answer 2

Существуют различия в SQL, который вам придется дать классам, в зависимости от типа движка базы данных, с которым вы разговариваете, поэтому даже если вам удастся написать весь код для использования интерфейсов, вы все равно нужно написать несколько наборов SQL.

Или, вы можете сделать то, что мы сделали, написать наш собственный слой, который заботится обо всем используемом синтаксисе, который не весь синтаксис, предоставляемый различными механизмами, но достаточно для написания одного SQL, который получает правильно переписано перед исполнением.

По сути, мы создали синтаксис функции, в котором мы добавляем SQL:: к именам функций, что позволяет нашему коду идентифицировать специальные функции, которые необходимо переписать. Затем они анализируются и переписываются должным образом, даже если необходимо изменить порядок аргументов при необходимости.

Можно сделать небольшие вещи, такие как имя функции, которая возвращает текущую дату и время сервера, но также и более важные вещи, например, как выбрать первые N строк запроса.

Кроме того, параметры для SQL Server записываются как @name, где OleDb использует позиционный (просто добавьте?, Где вы хотите параметр), и наш код также обрабатывает эти различия.

Это окупается в том смысле, что мы не особо беспокоимся о SQL, который нужно написать.

Answer 3

Я писал что-то похожее на то, что сказал Лассевк, но он побил меня.

Дополнительно , вам нужно поговорить с реальной базой данных в какой-то момент. Возможно, вам удастся скрыть большую часть доступа к данным с помощью кода интерфейса, и это хорошая идея. Но в конечном итоге, если вы используете SQL Server, вы захотите создать реальный экземпляр SqlClient.SqlConnection. То же самое для Access, Oracle или MySQL.

Answer 4

Вы должны попытаться написать независимую базу данных кода. Возможно, вы не находите это полезным сейчас, но, вероятно, воспользуетесь этим в будущем.

Answer 5

Я использую специфичные для поставщика классы, где я выполняю прямую работу с БД (если мне не сообщили, что есть вероятность, что мы можем использовать другую базу данных - сколько раз это происходило: один раз).

Однако, если я в итоге отделю некоторый код, не относящийся к БД, в отдельные классы, я часто делаю интерфейсы параметров метода - особенно если я думаю, что это будет полезно в других проектах, и я не полагаюсь ни на какие из особенностей класса прямого доступа.

По сути, перефразируя Эйнштейна: сделайте решение как можно более простым, но не более простым.

Answer 6

Взгляните на корпоративную библиотеку Microsoft Patterns and Practices группы Microsoft. У них есть код доступа к данным, показывающий несколько хороших реализаций независимости поставщика.

http://msdn.microsoft.com/en-us/library/cc467894.aspx