Коль скоро трехзвенка в данном случае сравнивается с двухзвенкой, то я предлагаю сразу вывести из рассмотрения веб-приложения (хотя их часто как раз и имеют в виду под 3-, и в более общем случае - под n-звенной архитектурой), и ограничиться такой схемой:
Толстый гуевый клиент - сервер приложения (бизнес-логика) - СУБД
Если возражений нет, то поехали дальше. Итак, у нас есть два альтернативных решения: зашить логику работы с базой непосредственно в клиента, либо спрятать ее в некой промежуточной сущности под названием сервер приложения. Если взглянуть на это дело, держа в руке бритву товарища Оккама, то может показаться, что всякие middle tier'ы нам совершенно ни к чему. Но это, товарищи, только на первый взгляд.
Важно понимать, что трехзвенная архитектура появилась на свет не как искусственное логическое построение, досужий вымысел яйцеголовых ИТ-идеологов, но как ответ на реальные трудности и ограничения, присущие исторически более раннему, двухзвенному подходу. В чем же заключались эти трудности? Давайте смотреть.
| Цитата |
| Между прочим, рассуждая сейчас об этих вещах, я сужу в том числе и с позиций своего опыта. Лет этак десять тому назад, когда только-только начали появляться средства разработки виндовозных программ, работающих с базами, я разрабатывал бухгалтерский программный комплекс на модном тогда SQLWindows. И в какой-то момент уперся в реальные трудности. И долго ломал голову, пытаясь найти выход. При этом просто спинным мозгом чувствовал, что должно быть какое-то простое и изящное решение. И когда наконец в ходе поисков наткнулся на инфу про трехвенную архитектуру, то сразу понял - дак вот же оно, именно то что нужно! |
Мышевозничество как прямая угроза системному дизайну
Одна из самых главных проблем двухзвенных приложений - это то, что датабазный код в них густо перемешан с оконной логикой. Тому есть естественные причины. Дело в том, что все поставщики средств разработки основной упор в продвижении своих инструментов делали на псевдо-легкость процесса создания программ. Тебе предлагался широкий выбор data-aware контролов, которые нужно было только натянуть мышкой на формочку - и все сразу начинало работать.
К сожалению, как практически любая попытка профанации серьезного процесса, мышечный способ создания датабазных программ приводит к появлению совершенно убогих приложений - напрочь лишенных какой бы то ни было внутренней архитектуры, деревянных в своей негибкости, подверженных синдрому "copy-paste", страдающих размытостью датабазной логики. На практике все эти особенности выливаются в следующее: когда в очередной раз вносятся коррективы в бизнес-требования, отразить эти изменения в програме оказывается настолько тяжело, что подчас подмывает просто все грохнуть и переделать по-новой. Что, естественно, не может быть приемлемой практикой.
Положение усугубляется тем обстоятельством, что далеко не каждый программист обладает достаточным программистским кругозором, чтобы осознать истинную причину своих затруднений. Как результат, многие дельфисты, VB-исты и иже с ними годами страдают херней, клепая и переклепывая мышкой свои датабазные формочки, и даже не ведают, что где-то рядом лежит истинный путь к нирване.
На самом деле даже в рамках двухзвенной архитектуры вполне возможно реорганизовать структуры программы таким образом, чтобы внести в процесс разработки некоторый порядок. Для этого надо сделать две вещи: напрочь отказаться от использования датабазных контролов и вынести все действия по работе с данными в отдельные невизуальные компоненты. Это сразу дает нам возможность использовать объектный подход как в программировании гуя, так и в датабазном слое. И если мы взглянем на ситуацию более внимательно, мы можем увидеть, что мы фактически сделали очень важный шаг по направлению к трехзвенной архитектуре: мы разнесли оконную и датабазную логику по разным углам, и попутно ввели в обиход объекты бизнес-сущностей, такие как Account, Customer, Invoice и т. д. - суть понятия, в терминых которых оконный слой может общаться со слоем датабазным.
К сожалению, даже реорганизовав программу описанным образом, мы по-прежнему не можем избавится от еще одной трудности, присущей двузвенной архитектуре - от проблемы конкурентного доступа.
Конкуренция - двигатель прогресса
Если бы программы писались в расчете на одного-единственного юзера, то на этом можно было бы и поставить точку: никакой нужды в отчленении рассмотреного выше датабазного слоя от клиентской программы и вынесении его в самостоятельную сущность просто бы не возникло. Но коль скоро в реальной жизни нам приходится иметь дело с множественными параллельно работающими юзерами, то это обстоятельство несколько меняет картинку. Итак, в чем же заключается проблема?
Во-первых, нам на клиентской машине нужен полноценный датабазный клиент и доступ к серверу СУБД по TCP/IP. Но это ладно.
Во-вторых, мы должны работать под своим отдельным логином. (чтобы было кого напинать по жопе в случае чего). Значит, кто-то должен администрить все эти аккаунты, добавлять права к различным объектам, следить, чтобы тот кому не нужно не получил слишком много прав, мониторить на предмет уязвимости и пр.
В-третьих, каждый клиент открывает и удерживает как минимум одно датабазное соединение, и закроет ли он его корректно - большой вопрос (тут имеется целый спектр возможностей, от сбоя винды до тривиального незакрытия проги). Подвисшие соединения неизбежно накапливаются, их надо время от времени мониторить, подчищать. Но да бог с ним, это заботы ДБ админа.
В-четвертых, и это будет поважнее: у нас резко возрастает возможность конфликтов. В хорошо нагруженной системе отнюдь не редкость, что в отдельный момент времени в СУБД выполняются сразу несколько транзакций, контролируемых различными клиентскими прогами. При этом, в зависимости от сложности и числа обращений к базе, вовлеченных в транзакцию, плюс еще целой кучи разных факторов, таких как заточенность структуры базы под конкурентный доступ, геометрия рук клиентского программера и пр., возможна огромная масса сценариев, когда результат работы нескольких параллельных транзакций не будет равен результату применения этих же транзакций по очереди. Как и где последствия этих конфликтов проявятся - предсказать заранее очень трудно, и когда они наконец попадут в базу, то отлавливание источника этих ошибок потребует от программера, ДБ админа и других заинтересованных людей сильнейшего напряжения мысли, ползания вдоль рулонов распечаток, многих литров кофе, массы смекалки, большого везения - и вовсе не факт, что все это увенчается успехом.
В-пятых, двузвенные приложения принципально не могут позволить себе кэшировать данные. Как следствие, за каждой порцией данных нужно обращаться к СУБД. Это тем более обидно, что значительная часть часто используемых данных имеет статическую природу и изменяются достаточно редко. В рамках трехзвенной архитектурв кэширование таких данных сервером приложения не представляет никакой трудности, и это обстоятельство существенно расширяет пределы масштабирования трехзвенки.
НУ и до кучи...
- Апдейт софта
Несоизмеримо проще контролировать согласованность клиентсих бинарников со структурой базы, когда вся датабазная логика сосредоточена в одном месте. - Разнообразие клиентов
В случае с двузвенкой у нас есть только один, данный на все времена, тип клиента, и логика работы с базой намертво зашита в его многочисленных обработчиках всяких кликов. Счастливо переиспользовать где-нибудь еще. А между тем бывает весьма удобно иметь несколько типов клиентов: для пакетной обработки, например. Или для интеграции с другой прогой. В случае с сервером приложения такое делается на раз. - Автоматическая готовность к вэбу
Имея сервер приложения, сделать его доступным для браузера - всего лишь вопрос приделывания к нему тонкого слоя вебного интерфейса. Попробуй-ка сделать то же самое с двухзвенным клиентом? - Доступность как веб-сервиса
При нынешних технологиях ремоутинга, сервер приложения превращается в набор веб-сервисов просто одним движением руки. И тогда твой сервер выбирается из тесной скорлупки и перед ним открывается все сияние мира.
И в заключение. batigoal, преимущества трехзвенной архитектуры настолько весомы и многочислены, что у меня просто не укладывается в голове, как ты мог повестись на дешевую агитку того упертого апологета двузвенки, который просто весь исходит на [censored33! Пожалуйста, соблюдайте элементарные правила приличия при общении на форуме], отстаивая свою позицию на форуме sql.ru. Даже если ты не в состоянии дать оценку качества аргументов, сама истерическая тональность выступлений сего аффтара должна была насторожить, не?
Ну да ладно, мир многополярный, каждый имеет право на собственное видение, и т. д. Пусть расцветают все цветы. Но отдельным чертополохам лучше бы сидеть в тени у забора
