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

Question

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

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

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

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

Должен ли я принимать ConnectionStrings как параметры в моем апи?

Должен ли я принимать IDbConnection как параметры в моем api?

Есть ли еще более подходящие способы сделать это - что было бы лучшим?

Answer 1

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

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

HTH. Jonathan

Answer 2

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

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

---

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

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