| 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 более "процедурный" язык. Реализовывать бизнес-логику на Оракле гораздо проще (имхо) чем на Сиквеле. Это мое имхо. Поэтому, я не думаю, что отказ от использования хранимых процедур серьезно упростит портирование системы на новую СУБД.
Вопрос\просьба в догонку. У кого-нибудь под рукой есть ссылки на статьи "авторитетных" авторов утверждающие что "слой доступа к данным - это хорошо"? То что это хорошо, я и так интуитивно понимаю (и делаю), но особенности менталитета начальника заставляют прибегать к авторитету сторонних специалистов.