Все нижесказанное – про техзвенку, однако в равной степени может быть применено к: архитектуре, модели, паттернам, технологиям... Итак.
Поскольку вопросы про трехзвенку появляются в форумах с завидной регулярностью, складывается впечатление, что очень многие наслышаны об ее чудодейственных свойствах и общем благотворном влиянии на разрабатываемый проект. В праведном желании узнать про трехзвенку как можно больше, эти многие сеют на полях форума вопросы, в которых, как правило, присутствует вопрос «как», и напрочь отсутствует вопрос «зачем». Второй же вопрос, на мой взгляд, представляется куда более сложным и важным, и мне непонятно – почему человек отвечает на него самостоятельно, и только затем идет на форум задавать второй.
Почему я считаю, что человек ответил на вопрос «зачем» скорее неверно, чем верно? То есть, почему использование терхзвенки в данном случае неоправданно? Причин две. Первая – поскольку человек не очень представляет, что такое трехзвенка (что вытекает из вопроса «как»), то скорее всего он ответил на вопрос «зачем» опираясь на чьи-то слова «Терхзвенка – это круто!» и прочих слухах. Вторая причина – человеку, не знающему «как» терхзвенку, скорее всего, поручили не очень сложный (большой) проект, необходимость терхзвенки в котором сомнительна.
На мой взгляд, классическая терхзвенка 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 во всех случаях автоматизации бизнес процессов, просто на всякий случай. Мне интересно почему такое-то решение или такая-то технология довольно часто принимаются на вооружение на основе пары статей и без должного анализа. Действует ли реклама? просто желание потрогать что-то новое? Что-то еще? Может кто знает, есть ли литература по поводу по поводу такого выбора, пытался ли это кто-либо формализовать... Даже не знаю пока чего хочу... просто мысли вот родились...
Мы уже победили, просто это еще не так заметно...
Если нам не помогут, то мы тоже никого не пощадим.
