Наткнулся тут на интересное обсуждение необходимости трехзвенной архитектуры: http://www.sql.ru/forum/actualthread.aspx?...214017&pg=1 (надо только отфильтровать те 75%, которые относятся к мерянью пиписьками).

А ведь действительно получается, что трехзвенная архитектура нафиг не нужна. Лишнее звено.

Прошу тех, кто имеет опыт работы с подобными системами, высказаться по поводу двух- и трёхзвенных решений. Какие преимущества может дать сервер приложений?

Это сообщение отредактировал(а) batigoal - 17.12.2006, 13:57

Тема действительно интересная, есть о чем поговорить. Только давайте сразу определимся с предметом обсуждения, а то под трехзвенной архитектурой можно понимать разные вещи.

Коль скоро трехзвенка в данном случае сравнивается с двухзвенкой, то я предлагаю сразу вывести из рассмотрения веб-приложения (хотя их часто как раз и имеют в виду под 3-, и в более общем случае - под n-звенной архитектурой), и ограничиться такой схемой:



Если возражений нет, то поехали дальше. Итак, у нас есть два альтернативных решения: зашить логику работы с базой непосредственно в клиента, либо спрятать ее в некой промежуточной сущности под названием сервер приложения. Если взглянуть на это дело, держа в руке бритву товарища Оккама, то может показаться, что всякие middle tier'ы нам совершенно ни к чему. Но это, товарищи, только на первый взгляд.

Важно понимать, что трехзвенная архитектура появилась на свет не как искусственное логическое построение, досужий вымысел яйцеголовых ИТ-идеологов, но как ответ на реальные трудности и ограничения, присущие исторически более раннему, двухзвенному подходу. В чем же заключались эти трудности? Давайте смотреть.



Мышевозничество как прямая угроза системному дизайну

Одна из самых главных проблем двухзвенных приложений - это то, что датабазный код в них густо перемешан с оконной логикой. Тому есть естественные причины. Дело в том, что все поставщики средств разработки основной упор в продвижении своих инструментов делали на псевдо-легкость процесса создания программ. Тебе предлагался широкий выбор data-aware контролов, которые нужно было только натянуть мышкой на формочку - и все сразу начинало работать.

К сожалению, как практически любая попытка профанации серьезного процесса, мышечный способ создания датабазных программ приводит к появлению совершенно убогих приложений - напрочь лишенных какой бы то ни было внутренней архитектуры, деревянных в своей негибкости, подверженных синдрому "copy-paste", страдающих размытостью датабазной логики. На практике все эти особенности выливаются в следующее: когда в очередной раз вносятся коррективы в бизнес-требования, отразить эти изменения в програме оказывается настолько тяжело, что подчас подмывает просто все грохнуть и переделать по-новой. Что, естественно, не может быть приемлемой практикой.

Положение усугубляется тем обстоятельством, что далеко не каждый программист обладает достаточным программистским кругозором, чтобы осознать истинную причину своих затруднений. Как результат, многие дельфисты, VB-исты и иже с ними годами страдают херней, клепая и переклепывая мышкой свои датабазные формочки, и даже не ведают, что где-то рядом лежит истинный путь к нирване.

На самом деле даже в рамках двухзвенной архитектуры вполне возможно реорганизовать структуры программы таким образом, чтобы внести в процесс разработки некоторый порядок. Для этого надо сделать две вещи: напрочь отказаться от использования датабазных контролов и вынести все действия по работе с данными в отдельные невизуальные компоненты. Это сразу дает нам возможность использовать объектный подход как в программировании гуя, так и в датабазном слое. И если мы взглянем на ситуацию более внимательно, мы можем увидеть, что мы фактически сделали очень важный шаг по направлению к трехзвенной архитектуре: мы разнесли оконную и датабазную логику по разным углам, и попутно ввели в обиход объекты бизнес-сущностей, такие как Account, Customer, Invoice и т. д. - суть понятия, в терминых которых оконный слой может общаться со слоем датабазным.

К сожалению, даже реорганизовав программу описанным образом, мы по-прежнему не можем избавится от еще одной трудности, присущей двузвенной архитектуре - от проблемы конкурентного доступа.

Конкуренция - двигатель прогресса

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

Во-первых, нам на клиентской машине нужен полноценный датабазный клиент и доступ к серверу СУБД по TCP/IP. Но это ладно.

Во-вторых, мы должны работать под своим отдельным логином. (чтобы было кого напинать по жопе в случае чего). Значит, кто-то должен администрить все эти аккаунты, добавлять права к различным объектам, следить, чтобы тот кому не нужно не получил слишком много прав, мониторить на предмет уязвимости и пр.

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

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

В-пятых, двузвенные приложения принципально не могут позволить себе кэшировать данные. Как следствие, за каждой порцией данных нужно обращаться к СУБД. Это тем более обидно, что значительная часть часто используемых данных имеет статическую природу и изменяются достаточно редко. В рамках трехзвенной архитектурв кэширование таких данных сервером приложения не представляет никакой трудности, и это обстоятельство существенно расширяет пределы масштабирования трехзвенки.

НУ и до кучи...

• Апдейт софта
  Несоизмеримо проще контролировать согласованность клиентсих бинарников со структурой базы, когда вся датабазная логика сосредоточена в одном месте.
  
• Разнообразие клиентов
  В случае с двузвенкой у нас есть только один, данный на все времена, тип клиента, и логика работы с базой намертво зашита в его многочисленных обработчиках всяких кликов. Счастливо переиспользовать где-нибудь еще. А между тем бывает весьма удобно иметь несколько типов клиентов: для пакетной обработки, например. Или для интеграции с другой прогой. В случае с сервером приложения такое делается на раз.
  
• Автоматическая готовность к вэбу
  Имея сервер приложения, сделать его доступным для браузера - всего лишь вопрос приделывания к нему тонкого слоя вебного интерфейса. Попробуй-ка сделать то же самое с двухзвенным клиентом?
  
• Доступность как веб-сервиса
  При нынешних технологиях ремоутинга, сервер приложения превращается в набор веб-сервисов просто одним движением руки. И тогда твой сервер выбирается из тесной скорлупки и перед ним открывается все сияние мира.

И в заключение. batigoal, преимущества трехзвенной архитектуры настолько весомы и многочислены, что у меня просто не укладывается в голове, как ты мог повестись на дешевую агитку того упертого апологета двузвенки, который просто весь исходит на [censored33! Пожалуйста, соблюдайте элементарные правила приличия при общении на форуме], отстаивая свою позицию на форуме sql.ru. Даже если ты не в состоянии дать оценку качества аргументов, сама истерическая тональность выступлений сего аффтара должна была насторожить, не?

Ну да ладно, мир многополярный, каждый имеет право на собственное видение, и т. д. Пусть расцветают все цветы. Но отдельным чертополохам лучше бы сидеть в тени у забора 

Тоже почитал первоисточник. Валентин К - это я лет эдак 12 назад. Если предположить, что я за это время глупее не стал, то доверять ему не стоит.  Stampede, +++.

Кстати, мне до сих неясны гносеологические, так сказать, истоки столь глубокого и искреннего заблуждения. С чем таким нужно было столкнуться в жЫзни, чтобы перестать видеть очевидное?

Действительно, в наше время когда "космические корабли бороздят...", подобная дремучесть удивляет. Ведь полно информации, легко убедиться в том что он не прав. Я понимаю, если бы человек в лесу жил без связи с миром. Но ведь это не так наверное. А так это напоминает попытку защитить лечение всех болезней кровопусканием.

Многая плюса Stampede 

Несмотря на столь подробное разжевывание и даже проглатывание, у меня, тем не менее, осталось несколько вопросов/сомнений. И главное из них упирается в следующий момент: 

• говоря о двухзвенке, я не подразумеваю толстого клиента и слой данных. Я подразумеваю логику в базе. Т.е. вот этот пункт:
  

  Цитата(Stampede @  18.12.2006,  23:45 )

  Итак, у нас есть два альтернативных решения: зашить логику работы с базой непосредственно в клиента, либо спрятать ее в некой промежуточной сущности под названием сервер приложения.

  
  в моем представлении выглядит несколько иначе. Логика работы с базой вообще будет отсутствовать в таком решении. База будет предоставлять интерфейс, и выполнять логическую обработку сама. Плюсы такого решения: "естественная" для природы БД транзакционность, отработанность решений по масштабированию (поставить вместо одного сервака кластер), низкие сетевые нагрузки, etc. Минусы: некоторые вещи тяжело провернуть на уровне базы (например, обработку картинок). Но! Это решаемо за счет подключения внешних процедур на Java или-что-там-еще-можно-подключить. Также есть проблемы при работе с вебом. Обрабатывать HTTP-запросы в базе - этого, кажется, на данном этапе никто не делает. Хотя, наверное, и это ограничение можно как-то обойти (через XSQL, например).

• Цитата(Stampede @  18.12.2006,  23:45 )

  Для этого надо сделать две вещи: напрочь отказаться от использования датабазных контролов и вынести все действия по работе с данными в отдельные невизуальные компоненты.

  
  Как я понимаю, ты говоришь об ORM-фреймворках? Или я не уловил идею?

• Цитата(Stampede @  18.12.2006,  23:45 )

  К сожалению, даже реорганизовав программу описанным образом, мы по-прежнему не можем избавится от еще одной трудности, присущей двузвенной архитектуре - от проблемы конкурентного доступа.

  
  А как трехзенка помогает решить проблему конкурентного доступа?
  Допустим, два юзера получили страницу с данными об объекте, находящемся в кэше аппликейшн-сервера. С секундной задержкой послали команду UPDATE. Как разруливать?

• Цитата(Stampede @  18.12.2006,  23:45 )

  В-пятых, двузвенные приложения принципально не могут позволить себе кэшировать данные.

  
  Тоже не ясный для меня момент. В моем нынешнем проекте существует толстый клиент, и самолепный кривой ORM-движок. И он как раз осуществляет клиентское кеширование данных. Сброс объекта в базу происходит только по команде object.save(). Или ты имеешь в виду, что объемы данных многих приложений не позволят клиенту такой роскоши?

Кажется, меня сейчас размажут, но я должен был это сказать 

P.S.

На личные выпады у меня стоит файрволл, поэтому я их не замечаю. И в большей степени меня на эту дискуссию сподвергло другое обстоятельство. Я сейчас, наконец, взялся за написание относительно большого проекта (пускай и никому, кроме узкого круга лиц, не интересного), и столкнулся с проблемой: какая часть логики должна быть в базе, а какая - снаружи?
Положа руку на сердце, вся логика на данном этапе может быть реализована на триггерах и хранимых проще, нежели на более высоком уровне.
Поэтому, убоявшись краха устоев моего мировоззрения, я полез в сеть за дискуссиями об оптимальном количестве звеньев архитектуры. И набрел на sql.ru c Валентином К.

P.P.S. К слову, схему buisness-компонента базы можно увидеть здесь: http://forum.vingrad.ru/index.php?showtopi...st&p=965972

Это сообщение отредактировал(а) batigoal - 19.12.2006, 10:01

Во, вот это уже гораздо ближе к телу!

Как это нередко бывает, вышло небольшое недоразумение, вызванное терминологической путаницей. Но это ничего страшного. Вообще на будущее: когда говорят о трехзвенной архитектуре, а тем более в противопоставлении архитектуре двузвенной, то практически без вариантов имеют в виду трехзвенную %5BB]клиент-серверную%5B/B] архитектуру, как частный случай клиент-серверной %5BB]сетевой%5B/B] архитектуры. И все рассуждения в моем предыдущем ответе относились именно к такому толкованию.

В данном случае, как я понимаю, речь идет о веб-приложении, с вариантом вынесения датабазной логики в хранимые процедуры. Правильно? Если да, то все вопросы, которые ты задаешь, теряют смысл, ибо мы говорим о двух совершенно разных вещах.

По сути вопроса отвечу после того как подтвердится правильность моей догадки. Тут тоже есть о чем поговорить 

ЗЫ. Если я все правильно понимаю, и ты хочешь сделать футбольный портал, то (в зависимости от серьезности твоих намерений), у меня (а может и не только у меня одного) может быть к тебе небольшие предложение.

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


А на этот вопрос я отвечу в ПМ. Причины: а) чтобы не оффтопить, б) потому что идеи у меня до конца не сформировались. 

У меня такой вопрос: если СУБД например оракл, в каком случае имеет смысл отказаться от промежуточного звена и вынести всю бизнес логику в БД на PL/SQL. А клиенты будут конектиться напрямую к СУБД или опять же оставить промежуточный уровень для разруливания запросов, но вся логика будет в БД, а промежуточный уровень будет неким транспортным узлом, что то типа диспетчера 

почитал статейку по первой ссылки  даааа................... у нас тут гораздо меньше вышло боталий 

Именно так у нас и есть сейчас в проекте. Огребаем мы на этом по-полной, потому что поддерживать достаточно сложную workflow-логику на PL/SQLе напряжно. Зато кастомизируется легко - подменил пакеты, и все.