Доступ к строкам подключения через веб-сервис

Question

Идея хранения строк подключения в базе данных является ошибочной идеей, но сначала выслушайте меня. Мы все знаем, что лучше всего шифровать строки подключения в файле web.config, но что, если мы просто полностью пропустим файл web.config?

Пару месяцев назад меня попросили переместить базы данных с одного сервера на другой. Это означало необходимость обновления строк подключения в каждой программе, которая обращалась к этим различным базам данных. Это третий раз за 2 года, когда мне приходилось перемещать базы данных с одного сервера на другой. Поэтому я подумал о хранении строк подключения в базе данных и назначении каждому GUID для доступа через веб-сервис. Вместо размещения строк подключения в файле web.config вам просто нужно сохранить GUID строки подключения в файле web.config и ссылаться на веб-службу строки подключения, чтобы можно было запросить эту строку подключения. Шифрование может выполняться на уровне приложения, а строки подключения просто хранятся в базе данных в зашифрованном виде.

Я создал доказательство концепции, и она отлично работает (работает только в локальной интрасети и не доступна в Интернете).

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

Но выгода не в том, что меня интересует. Мне интересно, что все здесь думают о том, чтобы сделать что-то подобное?

Answer 1

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

Answer 2

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

Answer 3

Очень интересный вопрос. Я нашел это, потому что у меня была та же идея.

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

Конечно, есть DNS, который решит проблему с именами хостов, но с таким веб-сервисом у вас есть невероятные возможности, такие как возврат различных строк подключения, в зависимости от того, кто спрашивает (в зависимости от, например, SSL-сертификата или пользователя / пароля или токена, службы каталогов, такие как AD, LDAP, роль пользователя и т. Д. - это предел неба:)

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

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

Answer 4

Я склонен делать одну из двух вещей. Я буду хранить соединения в Machine.Config, или я создам новое имя хоста, которое просто ссылается на сервер БД. Затем я помещаю запись в файл hosts.

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

Answer 5

Как насчет того, когда ваш веб-сервис меняет местоположение? Тогда вам все равно придется обновить все файлы web.configs.

Ваши приложения находятся на одном сервере или распределены по нескольким серверам? Вы можете отредактировать машину web.configs, чтобы включить стрингсы соединений с БД, чтобы сохранить много повторений.

Answer 6

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