Сформулирую вопрос по-четче.
Допустим, есть клиент-серверное приложение (WinForms). Для получения данных из БД и для модификации данных в БД можно у SqlCommand (например)
А) В CommandText'е прямо писать "Select.... Update... Delete" и т.д.
Б) В CommandText'е писать имя хранимой процедуры, в которой реализованы все эти select, delete и т.п.

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

Интересуют аргументы в пользу пункта А.
В пользу пункта Б приведу ряд своих аргументов, надеюсь услышать конструктивную критику. Вот они:
1) Хранимые процедуры позволяют абстрагироваться от структуры БД, от названий колонок и таблиц. В случае если потребуется переименовать какое-то поле, то не придется лазить по всему коду выиискивая где используется это поле, а просто через Dependency поднять хранимые процедуры использующие таблицу.
2) Хранимые процедуры легче отладить, чем отлаживать код приложения, делающий "сырой запрос". Процедуру я могу запустить в QueryAnalyser, и сразу убедится - хотя бы работает ли она? Если запрос сырой в коде, то остается только ловить SqlException в процессе функционального тестирования.
3) Если в нескольких местах программы требуется выполнить одинаковый запрос, то лучше вызвать в обоих местах хранимую процедуру, чем дублировать "сырой" sql-текст. (Конечно, проблема решается и без процедур, если есть "слой доступа к данным" в приложении, но мне с проектом не повезло и тут все запросы делаются прямо из форм - тяжелое наследие предшественников)
4) ?


В принципе, этот топик чем-то напоминает тему для Священной Войны.
Да простят меня модераторы. =(

З.Ы. Буду признателен за ссылки на статьи "умных людей" на эту тему.

Sa
Очень хилые в пользу ХП у Вас аргументы.
ИМХО:
1) Инкапсулировать структуру БД, лучше в отдельном слое программы. Можно вообще создать идеальную БД на базе DataSet и собирать данные из разрозненных БД информационной сети предприятия.
2) Что мешает отладить теже запросы в QA?
3) То что запросы делаются прямо из форм, не значит, что CommandText необходимо хранить там же, да и комм а нды можно получать из другого места.


Спасибо за контраргументы, однако:
1) Я согласен, что инкапсулировать структуру БД лучше в отдельном слое (в умных книжках его так и называют Data Access Layer), но реалии проекта таковы, что этого слоя нет и в помине. В процессе рефакторинга тяжелого наследия я этот слой создаю, но вместе с тем, я меняю прямые селекты на вызовы хранимых процедур. Проблема у меня возникла когда "начальник" попросил меня обосновать необходимость такого рода "переделок".
2) Если запрос параметризированный, то придется самому писать всякие Declare и Set параметров для отладки. В QA можно через object browser делать open у процедуры и задавать параметры. То есть, банально - хранимые процедуры удобней отлаживать.
3) Да, да. Это все к вопросу об организации слоя доступа к данным. Хорошо, аргумент снимается.

Sa
Что касается пункта А.
То один из плюсов - возможность создания программы одновременно поддерживающей несколько поставщиков СУБД - MS и Oracle без жесткой привязки к Transact SQL и PL SQL, например. Если есть слой данных, то можно легко перейти на другую СУБД, переписав этот слой.

А если слоя нет и в помине? Из форм прямо вызываются всякие SqlCommand и иже с ними. При переходе на новую СУБД по-любому придется сильно править и исходные коды и тексты sql-запросов. Синтаксис PL\SQL, на сколько я знаю, местами сильно отличается от TSQL (case'ы, top'ы). Да и вообще, после небольшого опыта работы с ораклом, у меня сложилось впечателение что для этих СУБД различается сам подход к написанию серверной логики. PL\SQL более "процедурный" язык. Реализовывать бизнес-логику на Оракле гораздо проще (имхо) чем на Сиквеле. Это мое имхо. Поэтому, я не думаю, что отказ от использования хранимых процедур серьезно упростит портирование системы на новую СУБД.

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

Sa
rgb-dart
А если слоя нет и в помине? Из форм прямо вызываются всякие SqlCommand и иже с ними.

Против лома нет приема. Изначально надо было отрывать руки, тому кто программу проектировал.

Поздно отрывать, они уже успели уволится.

Спасибо за ссылки - то что нужно! :)