как двигаются поршни нет, а вот как подходят провода и шланги, мне видеть не страшно.


!=

наверно симпатично будут смотреться статические поля отдельного класса. 

собственно пока так и делаю, ничего лучше не придумал

есть ещё вариант с отдельным resx файлом.

можно поюзать app.config. правда строки придется шифровать. это не сложно и не думаю, что очень долго. правда все зависит от твоих запросов.

Ну вот серьёзно - как мы вызываем какие-то запросы? Не создаём же дб-комманды каждый раз (непосредственно)?! Так или иначе, для нас это будет выглядить как dbContext.GetSomeEntities(param1, param2, param3). Следовательно напрашиваются два подхода: либо пишем методы и маппим их атрибутами, либо методы генерится чем-либо (второе, очевидно проще с точки зрения реалзиации, если не устраивают готовые решения). В первом случае запрос/имя хранимки очевидно будут параметрами атрибута (примеры: раз, два). Во втором - будет хранится в каком-то конфиге, а затем будет подставлено в код генератором. Всё.

Смысл хранить во внешнем конфиге можно придумать только один - у нас одну задачу могут решать несколько запросов и мы будем их переключать конфигом. Тем не менее тяжело назвать это удачным арихектурным решением (хотя универсального ответа нет - мало ли..).

конфиг я предложил только из-за 

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

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

Так, стоп. Давайте разберемся, кто тупит.
Топик стартер задал вопрос про хранение sql процедур. Хранить их естественно надо в классе ресурсов (и это не обязательно resx, это может быть любой класс), но из строк:



Я пришел к выводу, о паранои ТС, и к тому, что он пытается скрыться от рефлектора и пр.

Если моя исходная теория верна, то ТС, что то сдулся фразой:


Собирался скрываться, и тут бах решил все таки выложить. Если же, скрываться от рефлектора небыло желания, то мои фразы в стиле:


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

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

хотелось узнать кто как делает, может услышать дельные советы на эту тему.

вариант принят.



Это сообщение отредактировал(а) IGV - 18.8.2010, 14:38

Ну, с точки зрения классических абстракшен лейеров - это неверно. Слой бизнес-догики должен думать о бизнес-сущностях. О том, как посылать команды, работать с базной конекцией и т. д. "думает" слой доступа к данным (data access layer).

Любитель, согласен. Честно, вчера написал, перечитал - отправил. Сейчас прочитал твой топик, понял что написал бред. Хотя сделано верно, видимо путаюсь в терминалогии((((

Я использовал тупо хранимки и написал оболочку для вызовов хранимок вот так:


Вызовы выглядят так (тут есть недостаток в приведении к SqlDataReader), для меня это удобно было:

ДобренькийПапаша, одно но - не все БД поддерживают хранимые процедуры