Все нижесказанное – про техзвенку, однако в равной степени может быть применено к: архитектуре, модели, паттернам, технологиям... Итак.
Поскольку вопросы про трехзвенку появляются в форумах с завидной регулярностью, складывается впечатление, что очень многие наслышаны об ее чудодейственных свойствах и общем благотворном влиянии на разрабатываемый проект. В праведном желании узнать про трехзвенку как можно больше, эти многие сеют на полях форума вопросы, в которых, как правило, присутствует вопрос «как», и напрочь отсутствует вопрос «зачем». Второй же вопрос, на мой взгляд, представляется куда более сложным и важным, и мне непонятно – почему человек отвечает на него самостоятельно, и только затем идет на форум задавать второй.
Почему я считаю, что человек ответил на вопрос «зачем» скорее неверно, чем верно? То есть, почему использование терхзвенки в данном случае неоправданно? Причин две. Первая – поскольку человек не очень представляет, что такое трехзвенка (что вытекает из вопроса «как»), то скорее всего он ответил на вопрос «зачем» опираясь на чьи-то слова «Терхзвенка – это круто!» и прочих слухах. Вторая причина – человеку, не знающему «как» терхзвенку, скорее всего, поручили не очень сложный (большой) проект, необходимость терхзвенки в котором сомнительна.
На мой взгляд, классическая терхзвенка DB<-DataAccess<-Business<-UI вредна в:
большинстве web-проектов (за исключением очень крупных порталов с посещаемостью выше 10 тысяч в день и необходимостью в сложных и длительных процессах обработки данных)
во всех проектах, представляющих собой всего лишь интерфейс R/W к табличкам в базе данных. (Тем более если это веб проект – есть риск выполнять кучу лишних операций связанных с тем, что бизнес-объекты хранят свое состояние, а веб-программирование не располагает к хранению состояний объектов. Сделать это конечно можно, но придется затратить дополнительные усилия и породить дополнительное количество лишнего кода.)
В этих случаях лишние звенья способны только замедлить разработку и полностью запутать код, чем сделать затруднительным дальнейшее сопровождение и развитие. Такие проекты имеют тенденцию периодически переписываться с нуля.
Так в каких же случаях терхзвенка необходима? Я вижу следующие:
неопределенная четко изначально, но предполагаемая очень большая нагрузка на систему (здесь может помочь масштабируемость данной архитектуры)
необходима очень высокая устойчивость к сбоям (используя кластеры можно реализовать избыточность системы, и сбои в одном звене не выведут систему из строя)
очень сложные бизнес-процессы (если система должна выполнять операции, обрабатывающие большое количество информации и требующие большое количество времени – надежнее выполнять такие операции в выделенном бизнес-процессе)
очень жесткие требования к безопасности, когда некоторые данные, требуемые для выполнения некоторых операций не должны покидать сервер.
Заметьте, в каждом пункте есть слово очень.
Если ваша система удовлетворяет всем этим требованиям – смело берите трехзвенку на вооружение.
Если же вы не очень представляете, зачем оно вам нужно – подумайте, что для вас важнее: качественный и вовремя законченный проект или желание узнать «как».
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, ZevS, Вы писали:
GZ>Уважаемый ZevS. С первых строк вы начали путать понятия многозвенности и многослойности. Это совершенно разные понятия.
GZ>С уважением, Gleb.
Здравствуйте, 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.
Здравствуйте, GlebZ, Вы писали:
GZ> С первых строк вы начали путать понятия многозвенности и многослойности. Это совершенно разные понятия.
Добавлю лишь, что у врагов для этого есть целых два разных слова tier и layer. Соответственно tier — это физические слои DB, Application Server, Client tier. А layer — это логичесике Business layer, Data Access Layer...
При этом один логический слой может быть размазан по нескольким физическим.
Здравствуйте, GlebZ, Вы писали:
GZ>Многослойность — это абстракция и инкапсуляция некоторой функциональности. Все.
Я бы ещё добавил, что лучше понять назначение и необходимость введения слоёв можно, если рассматривать их в контексте слава "изоляция". Например, Data Access изолирует приложение от БД, Business Layer изолирует логику и данные от её потребителей, агенты (в терминологии MS) интерфейсы других систем от интерфейсов разрабатываемой системы. Бывают так же слои, изолирующие один отдел от другого, и даже иногда разработчиков друг от друга
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, GlebZ, Вы писали:
GZ>Тут судя повсему вы переключились действительно на трехзвенку ZS>>
ZS>>неопределенная четко изначально, но предполагаемая очень большая нагрузка на систему (здесь может помочь масштабируемость данной архитектуры) GZ>-1 GZ>БД — кластеризуются. Клиенты снижают нагрузку на БД. ZS>>необходима очень высокая устойчивость к сбоям (используя кластеры можно реализовать избыточность системы, и сбои в одном звене не выведут систему из строя) GZ>То же самое что и выше ZS>>очень сложные бизнес-процессы (если система должна выполнять операции, обрабатывающие большое количество информации и требующие большое количество времени – надежнее выполнять такие операции в выделенном бизнес-процессе) GZ>Нет, нет и нет. Перенос сложной логики на толстых клиентов дает более значительный выйгрыш в масштабируемости. Можно говорить только если у нас страдает канал доставки информации клиентам. То есть, когда данных настолько много, что перенос всех данных на клиента приводит к сипуке. ZS>>очень жесткие требования к безопасности, когда некоторые данные, требуемые для выполнения некоторых операций не должны покидать сервер. GZ>+2. Безусловно. ZS>>
Добавлю, что одно из важнейших свойств многозвенки было не упомянуто. А именно простота деплоймента и администрирования.
Спасибо, теперь верю.
В пример действительно забрались баги. Писал о многозвенке, но все эти Датааксес и Бусинес до того забили уже мозги что вписались как-то сами)))
Но вобщем я взял многозвенку как пример, что бы показать дизбаланс между горой информаци о том, что такое и как, и как мало написано про то,
в каких случаях это надо и почему.
...
Теперь по вашему тексту:
ZS>>На мой взгляд, классическая терхзвенка DB<-DataAccess<-Business<-UI вредна в: ZS>>
ZS>>большинстве web-проектов (за исключением очень крупных порталов с посещаемостью выше 10 тысяч в день и необходимостью в сложных и длительных процессах обработки данных) GZ>-1 за слои.
согласен, читать DB<-ApplicationServer<-Client, вместо DB<-DataAccess<-Business<-UI GZ>Если говорить о трехзвенке — то web-проекты при выделенной БД изначально трехзвенны. ZS>>во всех проектах, представляющих собой всего лишь интерфейс R/W к табличкам в базе данных. (Тем более если это веб проект – есть риск выполнять кучу лишних операций связанных с тем, что бизнес-объекты хранят свое состояние, а веб-программирование не располагает к хранению состояний объектов. Сделать это конечно можно, но придется затратить дополнительные усилия и породить дополнительное количество лишнего кода.) GZ>-1. GZ>Если хочешь сложно — возьми кодогенератор. Если хочешь сделать легко — пиши как следует. Многослойность у тебя сама получится.
вообще то тут вкралась многослойка, но все равно — не согласен. Ну зачем в сайте, который всего-лишь редактирует таблички лишний слой? На мой взгляд, это может быть оправдано только если те же классы с теми же табличками могут быть использованы повторно да еще и сторонними разработчиками... ZS>>
ZS>>В этих случаях лишние звенья способны только замедлить разработку и полностью запутать код, чем сделать затруднительным дальнейшее сопровождение и развитие. Такие проекты имеют тенденцию периодически переписываться с нуля. GZ>Строго наоборот. Цель многослойности — снижение сложности.
Правда? В чем вы измеряете сложность? Для меня многослойка оправдана если:
— необходима строгая типизация (что тоже не всегда удобно, так как во многих языках нужно изворачиваться для реализации nullable полей)
— клиент не должен (совсем не должен) знать что-либо о структуре базы.
вроде все. Добавте другие.
ZS>>Так в каких же случаях терхзвенка необходима? Я вижу следующие: GZ>Тут судя повсему вы переключились действительно на трехзвенку ZS>>
ZS>>неопределенная четко изначально, но предполагаемая очень большая нагрузка на систему (здесь может помочь масштабируемость данной архитектуры) GZ>-1 GZ>БД — кластеризуются. Клиенты снижают нагрузку на БД.
ну может быть.. ZS>>необходима очень высокая устойчивость к сбоям (используя кластеры можно реализовать избыточность системы, и сбои в одном звене не выведут систему из строя) GZ>То же самое что и выше ZS>>очень сложные бизнес-процессы (если система должна выполнять операции, обрабатывающие большое количество информации и требующие большое количество времени – надежнее выполнять такие операции в выделенном бизнес-процессе) GZ>Нет, нет и нет. Перенос сложной логики на толстых клиентов дает более значительный выйгрыш в масштабируемости. Можно говорить только если у нас страдает канал доставки информации клиентам. То есть, когда данных настолько много, что перенос всех данных на клиента приводит к сипуке. ZS>>очень жесткие требования к безопасности, когда некоторые данные, требуемые для выполнения некоторых операций не должны покидать сервер. GZ>+2. Безусловно. ZS>>
GZ>С уважением, Gleb.
Здравствуйте, Merle, Вы писали:
M>Добавлю лишь, что у врагов для этого есть целых два разных слова tier и layer. Соответственно tier — это физические слои DB, Application Server, Client tier. А layer — это логичесике Business layer, Data Access Layer... M>При этом один логический слой может быть размазан по нескольким физическим.
Более формальное но более правильное определение.
Здравствуйте, AndrewVK, Вы писали:
... AVK>Добавлю, что одно из важнейших свойств многозвенки было не упомянуто. А именно простота деплоймента и администрирования.
В сравнении в клиент-серверной архитектурой? Я то думал — чем больше в системе компонентов, тем сложнее деплоймент и администрирование...
Здравствуйте, ZevS, Вы писали:
AVK>>Добавлю, что одно из важнейших свойств многозвенки было не упомянуто. А именно простота деплоймента и администрирования.
ZS>В сравнении в клиент-серверной архитектурой?
Да.
ZS> Я то думал — чем больше в системе компонентов, тем сложнее деплоймент и администрирование...
Не совсем. В случае многозвенки есть возможность возложить управление деплойментом и клиентов и БД на сервер приложений. Если это реализовано, то танцев с бубном при установки и обновлении обычно требуется намного меньше.
...
AVK>Не совсем. В случае многозвенки есть возможность возложить управление деплойментом и клиентов и БД на сервер приложений. Если это реализовано, то танцев с бубном при установки и обновлении обычно требуется намного меньше.
Если я провильно понял, вы говорите уже о сопровождении/поддержке приложения, и тут я полностью согласен. Но первоначальное развертывание... не могли бы вы подробнее рассказать про "возможность возложить управление деплойментом и клиентов и БД на сервер приложений"?
Здравствуйте, ZevS, Вы писали:
ZS>Если я провильно понял, вы говорите уже о сопровождении/поддержке приложения, и тут я полностью согласен. Но первоначальное развертывание... не могли бы вы подробнее рассказать про "возможность возложить управление деплойментом и клиентов и БД на сервер приложений"?
Ну например, для деплоймента приложения в J2EE сервере обычно достаточно просто скопировать ear в специальный каталог. И все — структура БД, настройки самого сервера, CMP-контейнеры, все конфигурируется автоматически, без перезапуска сервера.
ZS>>>большинстве web-проектов (за исключением очень крупных порталов с посещаемостью выше 10 тысяч в день и необходимостью в сложных и длительных процессах обработки данных) GZ>>-1 за слои. ZS>согласен, читать DB<-ApplicationServer<-Client, вместо DB<-DataAccess<-Business<-UI
Очевидно ты не понял. -1 потому что для слоев это неверно. GZ>>-1. GZ>>Если хочешь сложно — возьми кодогенератор. Если хочешь сделать легко — пиши как следует. Многослойность у тебя сама получится. ZS>вообще то тут вкралась многослойка, но все равно — не согласен. Ну зачем в сайте, который всего-лишь редактирует таблички лишний слой? На мой взгляд, это может быть оправдано только если те же классы с теми же табличками могут быть использованы повторно да еще и сторонними разработчиками...
Логический слой выделяют для изоляции уже описанной IT, что есть частный случай инкапсуляции некоторой функицональности. В результате хорошего кода, после борьбы за повторное использование кода, ты должен получить структуру MVC. Что и есть некоторый частный случай многослойности о чем я уже упоминал. Даже для простых таблиц.
Надо учитывать следующее. Термины модульности и слоистости очень похожи друг на друга. И зачастую их в принципе нельзя отличить. А иногда их и не стоит отличать. Введешь модульность, а слоистость как правая рука боксера, когда надо будет сама пойдет.
Если ты уже на уровне архитектуры(или даже дизайна для маленьких программ) поймешь это, и сразу заложишь в программу, то только сэкономишь себе время.
ZS>>>
ZS>>>В этих случаях лишние звенья способны только замедлить разработку и полностью запутать код, чем сделать затруднительным дальнейшее сопровождение и развитие. Такие проекты имеют тенденцию периодически переписываться с нуля. GZ>>Строго наоборот. Цель многослойности — снижение сложности. ZS>Правда? В чем вы измеряете сложность?
Существуют достаточно много метрик сложности программных продуктов и метрик правильности продукта.
Рекомендую прочитать: http://www.ozon.ru/context/book_detail/id/1364355/ . Там даны основные используемые метрики при разработке программного обеспечения. ZS>Для меня многослойка оправдана если: ZS>- необходима строгая типизация (что тоже не всегда удобно, так как во многих языках нужно изворачиваться для реализации nullable полей) ZS>- клиент не должен (совсем не должен) знать что-либо о структуре базы. ZS>вроде все. Добавте другие.
Ты пытаешься найти некоторые частные случаи. А эти частные случаи могут лежать и в сфере предметной области. Их бесконечное количество.
Смотри, у нас есть цель. Бороться со сложностью разбивая на компоненты, и убирая повторное использование кода. У нас есть способ горизонтального разбития на компоненты. Называется — модульность. То есть мухи обрабатываются отдельно от котлет. Мы можем редактировать свойство мух независимо от котлет. И чем меньше связей между котлетами и мухами, тем больше вероятность что при изменении котлет мы можем не учитывать наличие мух. Но у нас есть также и похожие способы обработки. Разбиваем вертикально, и получается слоистость. В одном месте мы обрабатываем работу с БД, в другом месте обрабатываем показ на экран. И тут появляется одно вышеназванное свойство — изолированность. То есть, через слой у нас независимы не только реализации, но и даже интерфейсы. Это еще один огромнейший плюс. Изменения интерфейса в слое n гарантированно не затрагивает слои n-2 и слой n+2.
А дальше этими свойствами просто нужно пользоваться когда проектируешь архитектуру.
Стоп. Я не против различных подходов, делающих систему менее связанной и более гибкой. Но, почему-то, я уверен, что в одних случаях такой подход может быть оправдан, а в других нет. Я против того, что бы некое решение (много-звенка, -слойка, паттерны проектирования вообще, и даже технологии и средства) воспринималось как некая панацея. Если почитать в MSDNе, например, про SOA, можно заметить, что авторы рекомедуют использовать SOA во всех случаях автоматизации бизнес процессов, просто на всякий случай. Мне интересно почему такое-то решение или такая-то технология довольно часто принимаются на вооружение на основе пары статей и без должного анализа. Действует ли реклама? просто желание потрогать что-то новое? Что-то еще? Может кто знает, есть ли литература по поводу по поводу такого выбора, пытался ли это кто-либо формализовать... Даже не знаю пока чего хочу... просто мысли вот родились...