![]() |
Модераторы: LSD |
![]() ![]() ![]() |
|
batigoal |
|
|||
![]() Нелетучий Мыш ![]() ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: 4 Всего: 151 |
Наткнулся тут на интересное обсуждение необходимости трехзвенной архитектуры: http://www.sql.ru/forum/actualthread.aspx?...214017&pg=1 (надо только отфильтровать те 75%, которые относятся к мерянью пиписьками).
А ведь действительно получается, что трехзвенная архитектура нафиг не нужна. Лишнее звено. Прошу тех, кто имеет опыт работы с подобными системами, высказаться по поводу двух- и трёхзвенных решений. Какие преимущества может дать сервер приложений? Это сообщение отредактировал(а) batigoal - 17.12.2006, 13:57 -------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
Stampede |
|
|||
![]() Гносеолог ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 963 Регистрация: 25.4.2005 Где: Calgary, Alberta, Canada Репутация: 8 Всего: 144 |
Тема действительно интересная, есть о чем поговорить. Только давайте сразу определимся с предметом обсуждения, а то под трехзвенной архитектурой можно понимать разные вещи.
Коль скоро трехзвенка в данном случае сравнивается с двухзвенкой, то я предлагаю сразу вывести из рассмотрения веб-приложения (хотя их часто как раз и имеют в виду под 3-, и в более общем случае - под n-звенной архитектурой), и ограничиться такой схемой: Толстый гуевый клиент - сервер приложения (бизнес-логика) - СУБД Если возражений нет, то поехали дальше. Итак, у нас есть два альтернативных решения: зашить логику работы с базой непосредственно в клиента, либо спрятать ее в некой промежуточной сущности под названием сервер приложения. Если взглянуть на это дело, держа в руке бритву товарища Оккама, то может показаться, что всякие middle tier'ы нам совершенно ни к чему. Но это, товарищи, только на первый взгляд. Важно понимать, что трехзвенная архитектура появилась на свет не как искусственное логическое построение, досужий вымысел яйцеголовых ИТ-идеологов, но как ответ на реальные трудности и ограничения, присущие исторически более раннему, двухзвенному подходу. В чем же заключались эти трудности? Давайте смотреть.
Мышевозничество как прямая угроза системному дизайну Одна из самых главных проблем двухзвенных приложений - это то, что датабазный код в них густо перемешан с оконной логикой. Тому есть естественные причины. Дело в том, что все поставщики средств разработки основной упор в продвижении своих инструментов делали на псевдо-легкость процесса создания программ. Тебе предлагался широкий выбор data-aware контролов, которые нужно было только натянуть мышкой на формочку - и все сразу начинало работать. К сожалению, как практически любая попытка профанации серьезного процесса, мышечный способ создания датабазных программ приводит к появлению совершенно убогих приложений - напрочь лишенных какой бы то ни было внутренней архитектуры, деревянных в своей негибкости, подверженных синдрому "copy-paste", страдающих размытостью датабазной логики. На практике все эти особенности выливаются в следующее: когда в очередной раз вносятся коррективы в бизнес-требования, отразить эти изменения в програме оказывается настолько тяжело, что подчас подмывает просто все грохнуть и переделать по-новой. Что, естественно, не может быть приемлемой практикой. Положение усугубляется тем обстоятельством, что далеко не каждый программист обладает достаточным программистским кругозором, чтобы осознать истинную причину своих затруднений. Как результат, многие дельфисты, VB-исты и иже с ними годами страдают херней, клепая и переклепывая мышкой свои датабазные формочки, и даже не ведают, что где-то рядом лежит истинный путь к нирване. На самом деле даже в рамках двухзвенной архитектуры вполне возможно реорганизовать структуры программы таким образом, чтобы внести в процесс разработки некоторый порядок. Для этого надо сделать две вещи: напрочь отказаться от использования датабазных контролов и вынести все действия по работе с данными в отдельные невизуальные компоненты. Это сразу дает нам возможность использовать объектный подход как в программировании гуя, так и в датабазном слое. И если мы взглянем на ситуацию более внимательно, мы можем увидеть, что мы фактически сделали очень важный шаг по направлению к трехзвенной архитектуре: мы разнесли оконную и датабазную логику по разным углам, и попутно ввели в обиход объекты бизнес-сущностей, такие как Account, Customer, Invoice и т. д. - суть понятия, в терминых которых оконный слой может общаться со слоем датабазным. К сожалению, даже реорганизовав программу описанным образом, мы по-прежнему не можем избавится от еще одной трудности, присущей двузвенной архитектуре - от проблемы конкурентного доступа. Конкуренция - двигатель прогресса Если бы программы писались в расчете на одного-единственного юзера, то на этом можно было бы и поставить точку: никакой нужды в отчленении рассмотреного выше датабазного слоя от клиентской программы и вынесении его в самостоятельную сущность просто бы не возникло. Но коль скоро в реальной жизни нам приходится иметь дело с множественными параллельно работающими юзерами, то это обстоятельство несколько меняет картинку. Итак, в чем же заключается проблема? Во-первых, нам на клиентской машине нужен полноценный датабазный клиент и доступ к серверу СУБД по TCP/IP. Но это ладно. Во-вторых, мы должны работать под своим отдельным логином. (чтобы было кого напинать по жопе в случае чего). Значит, кто-то должен администрить все эти аккаунты, добавлять права к различным объектам, следить, чтобы тот кому не нужно не получил слишком много прав, мониторить на предмет уязвимости и пр. В-третьих, каждый клиент открывает и удерживает как минимум одно датабазное соединение, и закроет ли он его корректно - большой вопрос (тут имеется целый спектр возможностей, от сбоя винды до тривиального незакрытия проги). Подвисшие соединения неизбежно накапливаются, их надо время от времени мониторить, подчищать. Но да бог с ним, это заботы ДБ админа. В-четвертых, и это будет поважнее: у нас резко возрастает возможность конфликтов. В хорошо нагруженной системе отнюдь не редкость, что в отдельный момент времени в СУБД выполняются сразу несколько транзакций, контролируемых различными клиентскими прогами. При этом, в зависимости от сложности и числа обращений к базе, вовлеченных в транзакцию, плюс еще целой кучи разных факторов, таких как заточенность структуры базы под конкурентный доступ, геометрия рук клиентского программера и пр., возможна огромная масса сценариев, когда результат работы нескольких параллельных транзакций не будет равен результату применения этих же транзакций по очереди. Как и где последствия этих конфликтов проявятся - предсказать заранее очень трудно, и когда они наконец попадут в базу, то отлавливание источника этих ошибок потребует от программера, ДБ админа и других заинтересованных людей сильнейшего напряжения мысли, ползания вдоль рулонов распечаток, многих литров кофе, массы смекалки, большого везения - и вовсе не факт, что все это увенчается успехом. В-пятых, двузвенные приложения принципально не могут позволить себе кэшировать данные. Как следствие, за каждой порцией данных нужно обращаться к СУБД. Это тем более обидно, что значительная часть часто используемых данных имеет статическую природу и изменяются достаточно редко. В рамках трехзвенной архитектурв кэширование таких данных сервером приложения не представляет никакой трудности, и это обстоятельство существенно расширяет пределы масштабирования трехзвенки. НУ и до кучи...
И в заключение. batigoal, преимущества трехзвенной архитектуры настолько весомы и многочислены, что у меня просто не укладывается в голове, как ты мог повестись на дешевую агитку того упертого апологета двузвенки, который просто весь исходит на [censored33! Пожалуйста, соблюдайте элементарные правила приличия при общении на форуме], отстаивая свою позицию на форуме sql.ru. Даже если ты не в состоянии дать оценку качества аргументов, сама истерическая тональность выступлений сего аффтара должна была насторожить, не? Ну да ладно, мир многополярный, каждый имеет право на собственное видение, и т. д. Пусть расцветают все цветы. Но отдельным чертополохам лучше бы сидеть в тени у забора ![]() -------------------- "If you want something done right, do it yourself" По секрету: выучить английский - реально! |
|||
|
||||
tux |
|
|||
![]() Летатель ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 1853 Регистрация: 10.2.2005 Где: msk.ru Репутация: нет Всего: 132 |
Тоже почитал первоисточник. Валентин К - это я лет эдак 12 назад. Если предположить, что я за это время глупее не стал, то доверять ему не стоит.
![]() |
|||
|
||||
Stampede |
|
|||
![]() Гносеолог ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 963 Регистрация: 25.4.2005 Где: Calgary, Alberta, Canada Репутация: 8 Всего: 144 |
||||
|
||||
tux |
|
|||
![]() Летатель ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 1853 Регистрация: 10.2.2005 Где: msk.ru Репутация: нет Всего: 132 |
Действительно, в наше время когда "космические корабли бороздят...", подобная дремучесть удивляет. Ведь полно информации, легко убедиться в том что он не прав. Я понимаю, если бы человек в лесу жил без связи с миром. Но ведь это не так наверное. А так это напоминает попытку защитить лечение всех болезней кровопусканием. |
|||
|
||||
batigoal |
|
|||
![]() Нелетучий Мыш ![]() ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: 4 Всего: 151 |
Многая плюса Stampede
![]() Несмотря на столь подробное разжевывание и даже проглатывание, у меня, тем не менее, осталось несколько вопросов/сомнений. И главное из них упирается в следующий момент:
![]() 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 -------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
Stampede |
|
|||
![]() Гносеолог ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 963 Регистрация: 25.4.2005 Где: Calgary, Alberta, Canada Репутация: 8 Всего: 144 |
Во, вот это уже гораздо ближе к телу!
Как это нередко бывает, вышло небольшое недоразумение, вызванное терминологической путаницей. Но это ничего страшного. Вообще на будущее: когда говорят о трехзвенной архитектуре, а тем более в противопоставлении архитектуре двузвенной, то практически без вариантов имеют в виду трехзвенную %5BB]клиент-серверную%5B/B] архитектуру, как частный случай клиент-серверной %5BB]сетевой%5B/B] архитектуры. И все рассуждения в моем предыдущем ответе относились именно к такому толкованию. В данном случае, как я понимаю, речь идет о веб-приложении, с вариантом вынесения датабазной логики в хранимые процедуры. Правильно? Если да, то все вопросы, которые ты задаешь, теряют смысл, ибо мы говорим о двух совершенно разных вещах. По сути вопроса отвечу после того как подтвердится правильность моей догадки. Тут тоже есть о чем поговорить ![]() ЗЫ. Если я все правильно понимаю, и ты хочешь сделать футбольный портал, то (в зависимости от серьезности твоих намерений), у меня (а может и не только у меня одного) может быть к тебе небольшие предложение. |
|||
|
||||
batigoal |
|
|||
![]() Нелетучий Мыш ![]() ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: 4 Всего: 151 |
Как тебе сказать... Во-первых, веб-клиент абсолютно не подразумевается. Клиентов я хотел бы попробовать несколько. Однако, приложение по-любому будет распределенным, с удаленным клиетном. А вот по поводу вынесения логики в датабазный уровень - вот этого я все-таки буду по максимуму избегать. Хотя бы просто исходя из учебных целей, потому что моей целью является создание именно трехзвенного приложения. Согласен платить ценой потери производительности. А на этот вопрос я отвечу в ПМ. Причины: а) чтобы не оффтопить, б) потому что идеи у меня до конца не сформировались. -------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
Hidrag |
|
|||
![]() Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 877 Регистрация: 9.4.2005 Где: JDK Репутация: нет Всего: 25 |
У меня такой вопрос: если СУБД например оракл, в каком случае имеет смысл отказаться от промежуточного звена и вынести всю бизнес логику в БД на PL/SQL. А клиенты будут конектиться напрямую к СУБД или опять же оставить промежуточный уровень для разруливания запросов, но вся логика будет в БД, а промежуточный уровень будет неким транспортным узлом, что то типа диспетчера
![]() -------------------- ![]() |
|||
|
||||
chaos |
|
|||
![]() Серийный программист ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 2979 Регистрация: 7.7.2004 Где: Екатеринбург Репутация: нет Всего: 44 |
почитал статейку по первой ссылки
![]() ![]() |
|||
|
||||
batigoal |
|
|||
![]() Нелетучий Мыш ![]() ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: 4 Всего: 151 |
Именно так у нас и есть сейчас в проекте. Огребаем мы на этом по-полной, потому что поддерживать достаточно сложную workflow-логику на PL/SQLе напряжно. Зато кастомизируется легко - подменил пакеты, и все. -------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
![]() ![]() ![]() |
Правила ведения Религиозных войн | |
|
1. Уважайте собеседника 2. Собеседник != враг 3. Старайтесь воздерживаться от тем вида "Windows Rulez" или "Linux Rulez" С уважением, Smartov. |
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Религиозные войны | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |