Всем привет!

Может кто-нибудь объяснить мне неразумному, зачем везде твердится о необходимости создания отдельного слоя для работы кода ASP.NET с бизнес-логикой и СУБД?
Нигде не смог найти разумного ответа на этот вопрос.
Чаще всего видел фразы типа "А если программист ASP.NET выполняет запросы напрямую к СУБД из кода страницы - его сразу выгоняют с работы, т.к. это говорит о том, что он нифига не понимает в таких модных штуках, как n-звенные приложения"

Искренне не понимаю - нафига?

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

Хранимые процедуры и пользовательские функции позволяют использовать повторное использование кода :). Да и объект DataSet никто не отменяет - выбрал данные и пользуйся. Хотя его использование применительно к ASP.NET не совсем удачно будет, ИМХО. Проще делать выборки по запросу, еще и всегда актуальные данные будут. Ну а выборки делать через хранимки/функции

>2. поддерживаемость кода - это следствие из пункта 1 - если вы нашли
ошибку в DAL или BLL, то вы исправляете ее в одном месте, а не в дюжине, к примеру. Или вот еще пример: у вас поменялась БД, в случае n-tier архитектуры вам надо внести изменения только в один слой - DAL. BLL и UIL при этом останутся без изменений.

Нашел ошибку в хранимке - исправил - работает везде

А гипотетическое "у вас поменялась БД" - забавный аргумент :)
Я видел несколько систем, которые могли работать с целым спектром СУБД, т.к. используется n-tier. Выводы не утешительные по производительности.
Например есть система управления электронным контентом - Documentum
Работает с Oracle, MS SQL и еще кучей СУБД. Но для получения приемлемых результатов по производительности пришлось допиливать напильником базу, к примеру индексы создавать. А это следствие того, что "бизнес-логика отделена от хранилища" и промышленные СУБД используются чуть ли не как обычный файл-сервер, лучше бы тогда сразу в XML напрямую хранить данные...

>3. тестируемость кода и автоматизация тестирования - что для DAL, что для BLL написать Unit тесты можно, а вот для UIL - весьма затруднительно.

Никто не запрещает писать тесты (я бы даже сказал, что это необходимость, но до неё "дорасти" нужно) для хранимок. На уровне UIL только их вызов.

И в догонку
Я не против дополнительного слоя, но единственное место, где имеет смысл его делать - это WebServices для предоставления интерфейса к своему приложению для возможностей интеграции со сторонними приложениями.
В рамках же одного приложения - не понимаю зачем...
Следует использовать всё по назначению
СУБД для работы с данными и хранения бизнес-логики приложения
ASP.NET для создания интерфейса пользователя и работы с СУБД через хранимки
ИМХО

Еще забавно видеть, когда про код для работы n-tier, который раз в пять больше аналогичного, но с использованием нормального клиент-серверного подхода, говорят, что он более прозрачен и понятен. Насколько я могу делать выводы, исходя из просмотра форумов, единственный аргумент в пользу n-tier и программирования бизнес-логики на ООП-языках является отсутствие желания учить T-SQL или PL\SQL...

>Ну например для типизации сущностей без использования тормознутых датасетов.

Насколько я понимаю, вышесказанное относится к программированию бизнес-логики не на уровне СУБД?

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

Именно поэтому я и попросил рассказать, какие такие задачи требуют появления дополнительного слоя. Если быть более точным - то какие элементы бизнес-логики требуется программировать не на T-SQL или PL\SQL? Т.е. пример, когда бизнес-логику требуется вынести за рамки СУБД.

И вопрос к xopap:
Совершенно не верится в следующий тезис: "...разработку n-tier приложений гораздо проще контроллировать...". Нельзя ли привести пример, который бы показывал, что больший объем проще контролировать, чем меньший? И еще вопрос по поводу инструментальных средств, позволяющих визуально системному аналитику моделировать многоуровневую модель. Для варианта клиент-сервер это совсем не вопрос.

Все вопросы относятся применительно к разработке корпоративных систем на предприятиях, которые уже давно определились с выбором СУБД , выбрав для себя в качестве приоритетной обного из трех лидеров... Т.е. когда не имеет смысла фраза "смена СУБД на другую"

Я сделал для себя вывод:
Рано или поздно, но при использовании объектно-ориентированного подхода к моделированию информационных систем, встанет вопрос производительности
В итоге проект будет переведен на использование возможностей конкретной СУБД
Таким образом, многоуровневую архитектуру можно расценивать, как дорогое пилотное моделирование промышленого приложения.
При этом на этапе пилотного моделирования не стоит заморачиваться с выбором СУБД, а хранить данные в XML-файлах.

Забавно...

Но, если такие занятные штуки СУБД, как транзакции, индексы и иже с ними вас не интересуют, то можно оставить приложение и в такой реализации :)
В конце концов файл-серверная архитектура живет и поныне :)

>1. Кодебихайн WEB-страниц компактен и не загромождён кодом взаимодействия с БД (собственно средний уровень поделён на 2 части: 1) собственно класс для связи с БД и передачей и получением данных 2) бизнес-объекты)
Проще отладка
>2. Коснись дело разрабатывать win-формы (что было весьма возможно. если бы речь пошла о разработке ERP-системы...поскольку уж ASP.Net её делать уж сильно отважиться надо...хотя.... :-), то эти бизнес-объекты можно было бы юзать и там)
>3. В хранимых процедурах реализована бизнес-логика (порой весьма сложная),
на таблицах есть триггера, ограничения, функции........однако вся эта кухня скрыта от web-разработчиков

Насколько можно предположить из вышесказаного:
1. Были созданы обертки для вызова кода T-SQL
2. ВСЯ бизнес-логика лежала на СУБД
Вопрос:
"эти бизнес-объекты можно было бы юзать и там" - это про бизнес-объекты или все же про классы-обертки для вызова кода СУБД?

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