Многоразовые компоненты, соединения с базой данных и различные среды

Question

Мне интересно, что будет считаться наилучшей практикой при настройке повторно используемых компонентов / библиотек в .net. У меня есть веб-сервис, который использует библиотеку, которая содержит несколько соединений с базой данных для взаимодействия с базами данных. Мне интересно, как я должен настроить свою библиотеку, когда дело доходит до указания строк подключения.

Мне нужно иметь возможность изменять, к какой базе данных подключается повторно используемый компонент при развертывании в средах dev / uat / prod. Также существует определенная необходимость в возможности отследить, кто выполняет вызовы из базы данных - я мог бы захотеть узнать, кто является пользователем повторно используемого компонента, поэтому, если его используют веб-сервисы A и B, я мог бы захотеть использовать ws_A_usr в Строка подключения и аналогично для B.

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

Должен ли я читать строки подключения из конфигурации (MyLib.Properties.Settings.Default.abcConnectionString)

Должен ли я принимать строки подключения в качестве параметров в моем API?

Должен ли я принять IDbConnection в качестве параметров в моем API?

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

Answer 1

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

Вам нужна строка подключения в web.config вашего веб-сервиса, но вы хотите передать ее библиотеке через параметр в какой-то момент. Это позволит вам использовать ту же библиотеку в не веб-проекте. Также это позволит вам реализовать различные способы получения строки подключения (возможно, из вызова веб-службы).

НТН. Jonathan

Answer 2

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

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

---

Если вы не возражаете, предоставляя потребителям всю строку подключения, тогда разрешите всей строке жить в app.config или web.config. В частности, используйте функцию «Настройки приложения .NET 2.0» (Properties \ settings.settings). Это приведет к компиляции значений по умолчанию в сборку, но при использовании компонента эти значения по умолчанию будут записаны в файл app.config. Они могут быть отредактированы оттуда.

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