Sputnick,

я думаю нет. ты бизнес-логику вынес в отдельную библиотеку и настройка подключения к бд должна быть там. после сборки библиотеки site_bll конфиг будет переименован в site_bll.config и вместе с библиотекой положен в bin site_web.
при такой архитектуре достаточно удобно использовать эту библиотеку не только в web проекте но и в любом другом.

ZoriaЯ думаю как раз наоборот.
Если представить себе, что сайтов может быть несколько - обращаться должны к разным базам данных а библиотеку они могут использовать одну и ту же.. т.е через вебконфиг сайта должно быть возможно определить, с какой базой данных работает приложение.
у меня была библиотека для linktosql, в ней находится app.config c ключем строки подключения, допустим,
MyConnString. а чтобы для сайта бралась нужная строка подключения был переписан коструктор для DataContext()
: base
public CategoriesDataContext() :
base(global:: System.Configuration.ConfigurationManager.ConnectionStrings["MyConnString"].ConnectionString, mappingSource)
{OnCreated();}

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

также отмечу, что в нормальном процессе разработки сайтов минимум 2 - разработчика и стенд для тестирования. один обращается к базе MyDb, другой к MyTestDb.
то есть ваша библиотека должна уметь брать из конфига нужную строку подключения и передавать ее в ваш контекст БД.

способ Zoria хорош для мелких проектов. такие проекты тяжело сопровождать, так как в них операции обращения к БД присутствуют в aspx страницах. когда они перемешаны друг с другом - тяжело после другого человека разбираться.

ZoriamonstrU,

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

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

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

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

расскажу про архитектуру проекта , который достался мне на новой работе
1. есть веб сайта - админка и морда
2. есть windows сервис, который занимается запуском модулей системы (в ее терминах). модуль - это dll с методом Run. модулей можно задавать любое количество.
точки для конфигурования тут такие
1. морда
2. админка
3. модули - n штук

на морде использовался метод, который лезет в базу данных - GetUsers. вернее сказать его не было - я был вынужден его сделать.
этот метод мне понадобилось использовать в модуле, который вызывает GetUsers. метод использует подключение к БД.
теперь внимание вопрос - где указывать подключение к БД?
я кажется понял, в чем непонимание - я больше описываю то, где нужно конфигурировать подключение к базе, а не то, где его нужно хранить.
То есть в каком слое приложения это делать, а не то, где лежит connectionString.
в моем случае если строка подключения лежит в web, то откуда брать строку для модуля? он валяется в совершенно другом каталоге
, для выполнения запускается сервисом из третьего каталога - обратиться к конфигу web технически можно, но проблемно.
windows сервис можно запустить на другой машине. как оттуда к web обращаться ?

поэтому пришлось делать проект Model на Entity, а метод GetUsers вынести в проект Facade, к которой подключена Model.
к контексту Entity я обращаюсь в проекте Model.
там же лежит строка подключения к БД. при сборке этот app.config будет собран в model.config

в итоге в каталоге web админки будет лежать web.config и model.config, в каталоге windows сервиса будет лежать service_name.config и model.config.
в итоге я один и то же метод смог использовать в разных частях приложения. а физическое расположение бд определялось в момент запуска метода из библиотеки Facade - windows и веб проектам все равно откуда получены Users.

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

в принципе можно сэкономить и строки подключения подключать к web и windows сервису как ссылки

<connectionStrings configSource="strings.config" >
<add name="context" connectionString="my_string" providerName="System.Data.EntityClient" />
</connectionStrings>
то есть вне проекта web, windows (но в солюшене) сделать strings.config, и в сами проекта подключать файл как ссылки.
таки да - у вас получиться в web.config строка подключения в базе.
довольно удобно следить за текущими значениями строк подключения.
но это немножко обходной маневр(но допустимый).

в итоге - если у вас только два сайта в приложении - морда и админка - ради бога держите все в конфигах.
только если вам понадобиться методы для БД вынести в windows сервис (wcf, приписать нужное) у вас появиться n проблем.

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

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

он на свой вопрос получил два ответа
1. хранить в конфиге веба
2. не хранить в конфиге веба

ну надеюсь выберет свой путь :)

hVosttпо этому поводу есть не очень приличная, но довольно точная аналогия

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

объясняется сие умственной клаустрофобией. наука до сих пор верит, что это лечится

зачем вы это делаете ?

hVosttmonstrUзачем вы это делаете ?

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

между прочим архитектура, о которой я рассказал, мне не первый раз встречается. интересно - какой ваш способ конфигурирования такого приложения?

исходные данные такие :
У вас есть приложение. состоит из 3 частей
1. web морда
2. админка
3. windows сервис.
все три части лежат на разных машинах, обращаются к одной и той же базе.
как вы будете строить приложение ?

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

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

кстати разделять на слои далеко не я один предлагаю - в паттерне MVC так изначально есть деление.
так что если этот путь "через одно место", то весь ASP.NET MVC сделан через это место.
сколько людей работают, а мужики то не знают.