В многоуровневой структуре с отдельным слоем DataAccess в .NET, где должна управляться строка подключения?

Question

Существует давняя привычка, когда я работаю, чтобы строка подключения находилась в web.config, объект Sql Connection создается в блоке using с этой строкой подключения и передается в конструктор DataObjects (через метод CreateInstance конструктор является частным). Примерно так:

using(SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString))
{
    DataObject foo = DataObject.CreateInstance(conn);
    foo.someProperty = "some value";
    foo.Insert();
}

Это все пахнет для меня .. Я не знаю. Разве библиотека классов DataLayer не должна отвечать за объекты Connection и строки Connection? Буду признателен за информацию о том, что делают другие, или за хорошие статьи в Интернете о подобных дизайнерских решениях.

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

Answer 1

Мне нравится кодировать классы в моем слое доступа к данным, чтобы у них был один конструктор, который принимает IDbConnection в качестве параметра, а другой - строку (соединение).

Таким образом, вызывающий код может либо создать свой собственный SqlConnection и передать его (удобно для интеграционных тестов), смоделировать IDbConnection и передать его (удобно для модульных тестов), либо прочитать строку подключения из файла конфигурации (например, web). .config) и передайте это.

Answer 2

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

Я думаю, у меня был бы слой данных, который обеспечивает определенные DataInputs, то есть вещи, которые принимают условие и возвращают DataObjects. Такой DataInput теперь знает: «Эй, эти DataObjects хранятся в базе данных THAT, и с помощью конфигураций я могу использовать некоторую строку подключения для получения SQL-соединения оттуда.

Таким образом, вы инкапсулировали весь процесс «Как и откуда берутся объекты данных?» и внутренности слоя данных все еще могут быть проверены должным образом. (И, как побочный эффект, вы можете легко использовать разные базы данных или даже несколько разных баз данных одновременно. Такая гибкость, которая просто появляется, является хорошим признаком (tm))

Answer 3

это «запах» относительный. если вы абсолютно уверены в связи этого конкретного кода с SQL Server и записью строки подключения web.config, то все в порядке. если вы не заинтересованы в такой связи, я согласен с тем, что она является запахом кода и нежелательна.