Модераторы: LSD
  

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Трёхзвенная архитектура, "за" и "против" 
:(
    Опции темы
batigoal
Дата 17.12.2006, 13:57 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Нелетучий Мыш
****


Профиль
Группа: Участник Клуба
Сообщений: 6423
Регистрация: 28.12.2004
Где: Санктъ-Петербургъ

Репутация: 4
Всего: 151



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

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

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

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


--------------------
"Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли)
ЖоржЖЖ
PM WWW   Вверх
Stampede
Дата 18.12.2006, 22:45 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Гносеолог
**


Профиль
Группа: Участник Клуба
Сообщений: 963
Регистрация: 25.4.2005
Где: Calgary, Alberta, Canada

Репутация: 8
Всего: 144



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

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

Толстый гуевый клиент - сервер приложения (бизнес-логика) - СУБД


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

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

Цитата
Между прочим, рассуждая сейчас об этих вещах, я сужу в том числе и с позиций своего опыта. Лет этак десять тому назад, когда только-только начали появляться средства разработки виндовозных программ, работающих с базами, я разрабатывал бухгалтерский программный комплекс на модном тогда SQLWindows. И в какой-то момент уперся в реальные трудности. И долго ломал голову, пытаясь найти выход. При этом просто спинным мозгом чувствовал, что должно быть какое-то простое и изящное решение. И когда наконец в ходе поисков наткнулся на инфу про трехвенную архитектуру, то сразу понял - дак вот же оно, именно то что нужно!


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


--------------------
"If you want something done right, do it yourself"
По секрету: выучить английский - реально!
PM WWW   Вверх
tux
Дата 18.12.2006, 23:46 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Летатель
***


Профиль
Группа: Участник Клуба
Сообщений: 1853
Регистрация: 10.2.2005
Где: msk.ru

Репутация: нет
Всего: 132



Тоже почитал первоисточник. Валентин К - это я лет эдак 12 назад. Если предположить, что я за это время глупее не стал, то доверять ему не стоит. smile Stampede, +++.
PM MAIL Skype GTalk Jabber YIM   Вверх
Stampede
Дата 19.12.2006, 00:40 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Гносеолог
**


Профиль
Группа: Участник Клуба
Сообщений: 963
Регистрация: 25.4.2005
Где: Calgary, Alberta, Canada

Репутация: 8
Всего: 144



Цитата(tux @  18.12.2006,  13:46 Найти цитируемый пост)
Если предположить, что я за это время глупее не стал, то доверять ему не стоит.


smile

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

PM WWW   Вверх
tux
Дата 19.12.2006, 01:08 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Летатель
***


Профиль
Группа: Участник Клуба
Сообщений: 1853
Регистрация: 10.2.2005
Где: msk.ru

Репутация: нет
Всего: 132



Цитата(Stampede @  19.12.2006,  00:40 Найти цитируемый пост)
Кстати, мне до сих неясны гносеологические, так сказать, истоки столь глубокого и искреннего заблуждения. С чем таким нужно было столкнуться в жЫзни, чтобы перестать видеть очевидное?

Действительно, в наше время когда "космические корабли бороздят...", подобная дремучесть удивляет. Ведь полно информации, легко убедиться в том что он не прав. Я понимаю, если бы человек в лесу жил без связи с миром. Но ведь это не так наверное. А так это напоминает попытку защитить лечение всех болезней кровопусканием.
PM MAIL Skype GTalk Jabber YIM   Вверх
batigoal
Дата 19.12.2006, 09:59 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Нелетучий Мыш
****


Профиль
Группа: Участник Клуба
Сообщений: 6423
Регистрация: 28.12.2004
Где: Санктъ-Петербургъ

Репутация: 4
Всего: 151



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

Несмотря на столь подробное разжевывание и даже проглатывание, у меня, тем не менее, осталось несколько вопросов/сомнений. И главное из них упирается в следующий момент: 
  • говоря о двухзвенке, я не подразумеваю толстого клиента и слой данных. Я подразумеваю логику в базе. Т.е. вот этот пункт:
    Цитата(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(). Или ты имеешь в виду, что объемы данных многих приложений не позволят клиенту такой роскоши?
Кажется, меня сейчас размажут, но я должен был это сказать smile

P.S.
Цитата(Stampede @  18.12.2006,  23:45 Найти цитируемый пост)
batigoal, преимущества трехзвенной архитектуры настолько весомы и многочислены, что у меня просто не укладывается в голове, как ты мог повестись на дешевую агитку того упертого апологета двузвенки, который просто весь исходит на [censored33! Пожалуйста, соблюдайте элементарные правила приличия при общении на форуме], отстаивая свою позицию на форуме sql.ru. Даже если ты не в состоянии дать оценку качества аргументов, сама истерическая тональность выступлений сего аффтара должна была насторожить, не?

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

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

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


--------------------
"Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли)
ЖоржЖЖ
PM WWW   Вверх
Stampede
Дата 19.12.2006, 13:26 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Гносеолог
**


Профиль
Группа: Участник Клуба
Сообщений: 963
Регистрация: 25.4.2005
Где: Calgary, Alberta, Canada

Репутация: 8
Всего: 144



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

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

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

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

ЗЫ. Если я все правильно понимаю, и ты хочешь сделать футбольный портал, то (в зависимости от серьезности твоих намерений), у меня (а может и не только у меня одного) может быть к тебе небольшие предложение.
PM WWW   Вверх
batigoal
Дата 19.12.2006, 13:52 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Нелетучий Мыш
****


Профиль
Группа: Участник Клуба
Сообщений: 6423
Регистрация: 28.12.2004
Где: Санктъ-Петербургъ

Репутация: 4
Всего: 151



Цитата(Stampede @  19.12.2006,  14:26 Найти цитируемый пост)
В данном случае, как я понимаю, речь идет о веб-приложении, с вариантом вынесения датабазной логики в хранимые процедуры.

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

Цитата(Stampede @  19.12.2006,  14:26 Найти цитируемый пост)
ЗЫ. Если я все правильно понимаю, и ты хочешь сделать футбольный портал, то (в зависимости от серьезности твоих намерений), у меня (а может и не только у меня одного) может быть к тебе небольшие предложение. 

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


--------------------
"Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли)
ЖоржЖЖ
PM WWW   Вверх
Hidrag
Дата 14.2.2007, 13:36 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 877
Регистрация: 9.4.2005
Где: JDK

Репутация: нет
Всего: 25



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


--------------------
user posted image
PM WWW ICQ   Вверх
chaos
Дата 14.2.2007, 14:33 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Серийный программист
****


Профиль
Группа: Завсегдатай
Сообщений: 2979
Регистрация: 7.7.2004
Где: Екатеринбург

Репутация: нет
Всего: 44



почитал статейку по первой ссылки smile даааа................... у нас тут гораздо меньше вышло боталий smile
PM WWW   Вверх
batigoal
Дата 14.2.2007, 14:41 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Нелетучий Мыш
****


Профиль
Группа: Участник Клуба
Сообщений: 6423
Регистрация: 28.12.2004
Где: Санктъ-Петербургъ

Репутация: 4
Всего: 151



Цитата(Hidrag @  14.2.2007,  14:36 Найти цитируемый пост)
У меня такой вопрос: если СУБД например оракл, в каком случае имеет смысл отказаться от промежуточного звена и вынести всю бизнес логику в БД на PL/SQL. А клиенты будут конектиться напрямую к СУБД или опять же оставить промежуточный уровень для разруливания запросов, но вся логика будет в БД, а промежуточный уровень будет неким транспортным узлом, что то типа диспетчера smile 

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


--------------------
"Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли)
ЖоржЖЖ
PM WWW   Вверх
  
Ответ в темуСоздание новой темы Создание опроса
Правила ведения Религиозных войн
Smartov
1. Уважайте собеседника
2. Собеседник != враг
3. Старайтесь воздерживаться от тем вида "Windows Rulez" или "Linux Rulez"

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

 
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | Религиозные войны | Следующая тема »


 




[ Время генерации скрипта: 0.1241 ]   [ Использовано запросов: 21 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.