Здравствуйте, ZevS, Вы писали:

ZS>А обосновать?
Многозвенность — это уровень деплоинга. Ну например, у нас есть webклиент->webserver->DBMS — это трехзвенка. Или например webclient->aspwebserver->web сервер приложений->просто сервер приложений->DBMS. Это пятизвенка.
Логические слои(например вышеназванные вами DB<-DataAccess<-Business<-UI) — образуют слои которые могут находится и в одном исполняемом файле. Ну и соответсвенно, если слоев много и они явно выделены, то и называется это — многослойной архитектурой.

Ваша ошибка в том, что вы слишком превратно думаете о многослойности(подчеркну — это называется многослойность). Многослойность не обязательно должна быть сложной для реализации. И в этом его цель. Можно не сильно разделять между собой два понятия — инкапсуляция(абстракция) и слой. Они оба построены с одной целью — борьба со сложность. Под сложностью подразумевается не алгоритмическая сложность, или кол-во строчек кода, а именно сложность программ. Сложность программ значительно выше чем больше сущностей и связей между ними. Но при этом, следует учитывать, что локализуя различные связи в одном месте, мы уменьшаем сложность. Ну и сложность вытекает не только в трудность реализации, но и в трудность внесения изменений в программу. Именно последнее свойство чаще всего упоминается в связи с многослойностью. Многослойность — это абстракция и инкапсуляция некоторой функциональности. Все.

А теперь по частоте использования многослойности. В частности, если взять тот же паттерн MVC — то он и есть частный случай многослойности. Поэтому даже небольшая но внятно написанная программа, может держать все признаки многослойности. Даже если автор программы этого не подозревал.

Теперь по вашему тексту:

ZS>На мой взгляд, классическая терхзвенка DB<-DataAccess<-Business<-UI вредна в:
ZS>

ZS>
• большинстве web-проектов (за исключением очень крупных порталов с посещаемостью выше 10 тысяч в день и необходимостью в сложных и длительных процессах обработки данных)
  -1 за слои.
  Если говорить о трехзвенке — то web-проекты при выделенной БД изначально трехзвенны.
  ZS>
• во всех проектах, представляющих собой всего лишь интерфейс R/W к табличкам в базе данных. (Тем более если это веб проект – есть риск выполнять кучу лишних операций связанных с тем, что бизнес-объекты хранят свое состояние, а веб-программирование не располагает к хранению состояний объектов. Сделать это конечно можно, но придется затратить дополнительные усилия и породить дополнительное количество лишнего кода.)
  -1.
  Если хочешь сложно — возьми кодогенератор. Если хочешь сделать легко — пиши как следует. Многослойность у тебя сама получится.
  ZS>

ZS>В этих случаях лишние звенья способны только замедлить разработку и полностью запутать код, чем сделать затруднительным дальнейшее сопровождение и развитие. Такие проекты имеют тенденцию периодически переписываться с нуля.
Строго наоборот. Цель многослойности — снижение сложности.

ZS>Так в каких же случаях терхзвенка необходима? Я вижу следующие:
Тут судя повсему вы переключились действительно на трехзвенку
ZS>

ZS>
• неопределенная четко изначально, но предполагаемая очень большая нагрузка на систему (здесь может помочь масштабируемость данной архитектуры)
  -1
  БД — кластеризуются. Клиенты снижают нагрузку на БД.
  ZS>
• необходима очень высокая устойчивость к сбоям (используя кластеры можно реализовать избыточность системы, и сбои в одном звене не выведут систему из строя)
  То же самое что и выше
  ZS>
• очень сложные бизнес-процессы (если система должна выполнять операции, обрабатывающие большое количество информации и требующие большое количество времени – надежнее выполнять такие операции в выделенном бизнес-процессе)
  Нет, нет и нет. Перенос сложной логики на толстых клиентов дает более значительный выйгрыш в масштабируемости. Можно говорить только если у нас страдает канал доставки информации клиентам. То есть, когда данных настолько много, что перенос всех данных на клиента приводит к сипуке.
  ZS>
• очень жесткие требования к безопасности, когда некоторые данные, требуемые для выполнения некоторых операций не должны покидать сервер.
  +2. Безусловно.
  ZS>

С уважением, Gleb.