IdbConnection vs SqlConnection

Question

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

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

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

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

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

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

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

• Vendor определенных ключевых слов, встроенных в селектах заявления (все мои модули, UPD, & дель находятся в проках, так что не проблема)
• Прямая привязка базы данных , вероятно, вызовет проблемы .
• Если ваше соединение было централизовано, то в любом случае необходимо назвать определенному классу поставщика.

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

В принципе, перефразируя Эйнштейна: Сделайте решение максимально простым, но не проще.

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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