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

Близкие,

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

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

А) Это кажется правильным, и

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

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

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

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

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

Спасибо за уделенное время!


asp.net web-config data-access-layer 3-tier n-tier-architecture
person bnieland    schedule 29.09.2010    source источник

Ответы (3)


arrow_upward
2
arrow_downward

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

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

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

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

person Brad    schedule 29.09.2010

arrow_upward
2
arrow_downward

Пока их не слишком много, удобно иметь их в 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. Для меня это просто потому, что я не хотел делать отдельный файл конфигурации.

person Patrick Karcher    schedule 29.09.2010

arrow_upward
0
arrow_downward

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

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

person gandjustas    schedule 29.09.2010