Как в приложении лучше всего реализовать хранение SQL выражений?

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

Вариант с простым вынесением их, например в xml-файл, не пойдет, т.к. запросы должны быть скрыты от "злоумышленника" ))).
Файл Resources.resx тоже не вариант, т.к. там хранятся интерфейсные вещи, не хочется их смешивать.




Это сообщение отредактировал(а) IGV - 13.8.2010, 13:15

IGV, для этого есть хранимые процедуры.

Добавлено через 11 секунд
да и не только для этого

Добавлено через 4 минуты и 14 секунд

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

gambit, 
причем здесь хранимые процедуры??? 
нет никакой разницы что в этой строке наименование хранимой процедуры или напрямую запрос SELECT?

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

Из строки

я подумал что вы именно код храните.


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

Это сообщение отредактировал(а) gambit - 13.8.2010, 15:57

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

Это сообщение отредактировал(а) IGV - 13.8.2010, 17:28

IGV, а что мешает хранить ресурсы в зашифрованном виде, и расшифровывать их на лету.

ну если не первый, то один из первых. Я никогда не слышал, что бы для кого то было проблемой хранение имен sql процедур.
Кого я сегодня на работе поспрашивал, все ответили примерно след:

Я тоже за хранение запросов в том же самом XML, только в зашифрованном виде
можешь до кучи ещё к какому ни будь зашифрованной строке применить свой сдвиг или ещё чего.

Ребят, вы издеваетесь или как?  Если у человека есть прямой доступ к базе, то всегда есть SQL Profiler (ну или аналогичная тулза, в случае не MS SQL). А если у вас обычная SOA - то что вы скрывать собрались?

Это сообщение отредактировал(а) Любитель - 14.8.2010, 11:38

А где об этом сказано?

Если у приложения есть прямой доступ, то у человека тоже. В худшем случае, это файловая база с поддержкой шифрования - может не быть пароля, но.. Я думал времена таких извращений прошли. Разве нет?

А что вы называете прямым доступом? что храниться строка подключения или что пароль имеется? Из этого - строка без пароля ничего не дает, пароль в программе может не храниться.
Или например, проект asp.net. Имеется проект, в нем строка подключения, даже с паролем. Подключается к базе "напрямую". Я выложил проект в сети, ну и получите доступ к базе.

Какая-т путаница у вас.

Если уж говорите про чистовебовые приложения, то задам вопрос ещё раз - зачем вы собрались шифровать запросы?! 
В случае веб-приложения клиентская часть - это HTML/JS (ну и там флеш, сильверлайт - не суть). Веб-приложения дают "автоматом" сервис-ориентированную архитектуру (с точки зрения клиента, а не с точки зрения АПИ сервиса) всегда. Шифровать тут (в плане общения с базой) нечего.

Про базы, расшифроваемые налету я уже говорил - это потеряло актуальность (по крайней мере в том виде, как это было раньше). Т. к. тут всё классически, какие-то дампы всегда сделать можно, поэтому, если данные дейтствильно нельзя давать юзеру - то это надо пресекать совсем. Доступа к базе у него не должно быть. Он должен общаться только с сервисом. Ну и какое тут шифрование запросов?!

По теме: либо использовать орм, либо хранимки (можно вместе, но эт не имеет отношения к вопросу). И дело, конечно, ни в каком не шифровании - просто поддерживать иначе сложно. А сам "список" процедур - вполне можно хранить константами где-нибудь. На практике, если не используют "тяжёлые" ОРМ, то самый тру-вей - генерить обёртки для вызова процедур. Сам список в каком-нибудь XML-е, читаемым только тулзой для генерации класса/классов.

Я ничего не собрался)))


топик стартеру не понравилось(((



а вот от этого, топикстартер вообще в ужасе.

Да, я вначале не на твою цитату отвечал. Меня просто ужаснула идея шифрования.

эм...вот яркий пример когда из обычного вопроса получается нечто....извращенцы )))))
вопрос был простым. а они уже в шифрование полезли...

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

Ну раз такое дело, то пусть это будут не SQL-выражения, а просто строки и неважно, что в них. И их много.
Вариант с текстовым фалом принят. что ещё?