Где следует хранить строки подключения в n-уровневом приложении asp.net - PullRequest
Новая
       46

Где следует хранить строки подключения в n-уровневом приложении asp.net

5 голосов
/ 30 сентября 2010

Люди,

У меня есть проект ASP.NET, который довольно n-уровневый по пространству имен, но мне нужно разделить его на три проекта: Уровень данных, Средний уровень и Front End.

Я делаю это, потому что ...

А) Кажется, это правильно, и

B) У меня возникают всевозможные проблемы с запуском модульных тестов для сборок ASP.NET.

В любом случае, мой вопрос: где вы храните информацию о конфигурации?

Например, сейчас мои классы среднего уровня (использующие Linq to SQL) автоматически извлекают информацию о своих строках соединения из web.config при создании нового контекста данных.

Если мой слой данных находится в другом проекте, может / должен ли он использовать web.config для информации о конфигурации?

Если это так, как модульный тест (обычно в отдельной сборке) предоставит информацию о конфигурации soch?

Спасибо за ваше время!

Ответы [ 3 ]

2 голосов
/ 30 сентября 2010

Мы храним их в глобальном файле «Настройки», который является XML.Этот файл содержит все настройки GLOBAL, одной из которых является строка подключения, указывающая на соответствующий сервер , а также имя пользователя и пароль.Затем, когда мои приложения используют его, они помещают нужный каталог (базу данных) в строку подключения.

У нас есть версия файла для каждой операционной среды (prod, dev, staging и т. Д.).Затем с двумя настройками - путем к файлу (с токеном, представляющим среду) и средой - я могу подобрать правильные файлы настроек.

Это также имеет приятное преимущество - 30-секундное восстановление после отказа.Просто измените имя сервера в файле настроек и перезапустите приложения (Интернет), и вы перешли на другой ресурс (разумеется, вам необходимо восстановить ваши данные при необходимости).

Затем, когда приложение запускается, мы пишем правильноестрока подключения к файлу web.config (если он другой).Благодаря этому мы можем изменить веб-сайт с DEV на PROD, изменив одно значение appSettings.

2 голосов
/ 30 сентября 2010

Пока их не так много, удобно иметь их в web.config.Конечно, ваш DAL не должен иметь никакого представления о том, что он оттуда.

Хорошим вариантом является предоставление вашему слою данных информации о его конфигурации, когда он призван что-то сделать, и он будет вызванчто-то делать, когда поступает веб-звонок. Идите вперед и поместите информацию в ваш web.config.В моем текущем проекте у меня есть статический словарь строк соединений в моем слое данных, который я заполняю примерно так в процедуре, вызываемой из моего global.asax: 

CAPPData.ConnectionStrings(DatabaseName.Foo) = 
    ConfigurationManager.ConnectionStrings("FooConnStr").ConnectionString()
CAPPData.ConnectionStrings(DatabaseName.Bar) = 
    ConfigurationManager.ConnectionStrings("BarConnStr").ConnectionString()
etc.

«Внедрение» этого так может подходить для целей автоматического тестирования, в зависимости от того, как / если вы тестируете свой DAL.Для меня это просто потому, что я не хотел создавать отдельный файл конфигурации.

0 голосов
/ 30 сентября 2010

В целях тестирования не создавать экземпляр DataContext с ctor по умолчанию.Передайте информацию о строке подключения в конструктор.

Я предпочитаю использовать платформы IoC для внедрения соединения в контекст данных, а затем для вставки контекста в другие классы.

...