Трехслойка vs Двухслойка

← →
ANB © (2006-01-31 10:15) [0]

Есть ли хоть какие нибудь аргументы, говорящие в пользу трехслойки ?
СУБД, есно, Оракл.

Имхо :
Трехслойку тяжелее писать и труднее сопровождать. А преимуществ нету.

← →
by © (2006-01-31 10:27) [1]

В свое время я писал одно трехзвенное приложение что бы упростить установку клиентской части, так как на клиенте не нужно было бы настраивать BDE и пр. Но сейчас есть компоненты доступа которые работают и без клиента Oracle (тот же ODAC).
Еще одним аргументом было то что при трехзвенке лучше выполняются операции типа расчета амортизации, когда нужно перелопатить данные и получить результат, на клиента это тянуть не хочется.
Но опять же, в случае Oracle это красиво запихивается в пакеты.
Я сейчас пишу только клиент-сервер для Oracle.
Трехзвенка нужна тогда, наверное, если к одной логике хочется прилепить и rich клиент и web интерфейс.
Но опять же, в случае Oracle с web отлично справляется iAS.
Так что пока обойдемся двухзвенкой.

← →
Карелин Артем © (2006-01-31 10:28) [2]

Более тонкое управление клиентами и их правами, меньше нагрузки на клиента.
3-звенки на ОЧЕНЬ ТОНКИХ клиентах типа броузеров рулят.

← →
unknown © (2006-01-31 10:32) [3]

У меня сейчас предстоит переход на 3-х звенку - для разгрузки канала связи
(128 кб всего)

← →
seg (2006-01-31 10:35) [4]

У меня сейчас предстоит переход на 3-х звенку - для разгрузки канала связи
(128 кб всего)

Может дешевле более быстрый канал оплатить?

← →
Sandman29 © (2006-01-31 10:37) [5]

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

← →
ANB © (2006-01-31 10:37) [6]

> Более тонкое управление клиентами и их правами, меньше нагрузки
> на клиента.
> 3-звенки на ОЧЕНЬ ТОНКИХ клиентах типа броузеров рулят.

1. Тонкое управление доступом прекрасно делается на уровне пакетов оракла и динамического SQL с возвратом на клиента курсора
2. Очень тонкий клиент типа броузера IE прекрасно и легко пишется на PL/SQL. Тут тогда вообще однослойка получается.

← →
by © (2006-01-31 10:38) [7]

unknown © (31.01.06 10:32) [3]
У меня сейчас предстоит переход на 3-х звенку - для разгрузки канала связи
(128 кб всего)
А сколько клиентов то? У нас биллинг на 128к при десятке клиентов пристойно работал и на клиент сервере - естесвенно вся логика в пакетах сервера.

← →
unknown © (2006-01-31 10:39) [8]

>seg (31.01.06 10:35) [4]
Да нет, к сожалению, не дешевле.
Это радио канал между двумя городами.

← →
Игорь Шевченко © (2006-01-31 10:39) [9]

> Есть ли хоть какие нибудь аргументы, говорящие в пользу
> трехслойки ?

Масштабируемость

← →
seg (2006-01-31 10:39) [10]

1. Тонкое управление доступом прекрасно делается на уровне пакетов оракла и динамического SQL с возвратом на клиента курсора
2. Очень тонкий клиент типа броузера IE прекрасно и легко пишется на PL/SQL. Тут тогда вообще однослойка получается.

Абсолютно согласен.
2-х звенка и web интерфейс на PL/SQL рулят адназначна и запихивают в ж.. всякие .NET технологии.

← →
ANB © (2006-01-31 10:41) [11]

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

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

← →
seg (2006-01-31 10:41) [12]

Да нет, к сожалению, не дешевле.

Может запросы пересмотреть и не тянуть большие объемы данных на клиент, а обрабатывать на сервере, а клиенту возвращать только готовый результат?

← →
Reindeer Moss Eater © (2006-01-31 10:42) [13]

3-звенки на ОЧЕНЬ ТОНКИХ клиентах типа броузеров рулят.

В чем они рулят-то?
Функционала чуть, зато html тэгов на единицу полезных данных - вагон и маленькая тележка.

← →
unknown © (2006-01-31 10:43) [14]

>by © (31.01.06 10:38) [7]
Клиентов в пределах 30-ти, в клиент-серверном варианте траффика набегает
в пределах 3 Гб в месяц (на каждого клиента).
В разрабатываемом варианте раза в 4 меньше.

← →
ANB © (2006-01-31 10:43) [15]

> Масштабируемость

А у двухслойки нет масштабируемости (если грамотно писать, есно) ?

> Да нет, к сожалению, не дешевле.
> Это радио канал между двумя городами.

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

← →
Lamer@fools.ua © (2006-01-31 10:47) [16]

Про n-tier флейма уже достаточно понаписано. Например, здесь:
http://sql.ru/forum/actualthread.aspx?tid=214017&pg=1

← →
Игорь Шевченко © (2006-01-31 10:47) [17]

ANB © (31.01.06 10:43) [15]

> А у двухслойки нет масштабируемости (если грамотно писать,
> есно) ?

Нет. А откуда она возьмется ?

← →
Sandman29 © (2006-01-31 10:47) [18]

ANB © (31.01.06 10:41) [11]

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

Все равно известно, где первая БД, которую можно взломать. А в трехзвенке вообще непонятно, есть ли БД как таковая :)
А если я захочу перейти с Oracle на Informix, например, то мне не придется менять код клиента и искать аналог ODAC.

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

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

← →
ANB © (2006-01-31 10:48) [19]

> unknown © (31.01.06 10:43) [14]

PACKAGE utl_tcp. И не надо среднего звена.

> Reindeer Moss Eater © (31.01.06 10:42) [13]
> 3-звенки на ОЧЕНЬ ТОНКИХ клиентах типа броузеров рулят.
>
> В чем они рулят-то?
> Функционала чуть, зато html тэгов на единицу полезных данных
> - вагон и маленькая тележка.

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

← →
Digitman © (2006-01-31 10:49) [20]

> ANB © (31.01.06 10:41) [11]

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

Интерпретирующие же системы всегда проигрывают в производительности нативным системам.

← →
ANB © (2006-01-31 10:51) [21]

> Lamer@fools.ua © (31.01.06 10:47) [16]

Не приставай. Про политику спорить то запретили.

> Нет. А откуда она возьмется ?

Хм. Может не понимаю я чего в термине "Масштабируемость" ?
Можно поподробнее, чего можно сделать такого в треслойке, чего нельзя в двухслойке ?

← →
Reindeer Moss Eater © (2006-01-31 10:51) [22]

Я реально не смог обойтись без трехзвенки когда потребовалось обеспечить одновременный доступ к нескольким (вообще любым) серверам раскиданным по всей корпоративной сети.

← →
roottim © (2006-01-31 10:52) [23]

Функционала чуть, зато html тэгов на единицу полезных данных

AJAX, DHTML, SOAP, XML-RPC решает указанные роблемы и фактически делает web почти gui приложением

← →
Sandman29 © (2006-01-31 10:53) [24]

Reindeer Moss Eater © (31.01.06 10:51) [22]

+ если хранить часть данных не в БД, а в виде файлов, то не приходится давать всем встречным доступ к хранилищам

← →
Игорь Шевченко © (2006-01-31 10:54) [25]

ANB © (31.01.06 10:51) [21]

> Можно поподробнее, чего можно сделать такого в треслойке,
> чего нельзя в двухслойке ?

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

← →
Sergey13 © (2006-01-31 10:54) [26]

2 [3] unknown © (31.01.06 10:32)
>У меня сейчас предстоит переход на 3-х звенку - для разгрузки канала связи(128 кб всего)

Не факт, что 3-звенка решит эту проблему. Автоматом точно не решит. ИМХО.

← →
seg (2006-01-31 10:56) [27]

что хранимые процедуры интерпретируются ядром сервера (точней интерпретируется некий промежуточный код, полученный в рез-те прекомпиляции сервером текста ХП),

Но на ХП можно вместо долгих запросов использовать курсоры, которые ускоряют работу в сотни раз!

← →
ANB © (2006-01-31 10:57) [28]

> Все равно известно, где первая БД, которую можно взломать.
> А в трехзвенке вообще непонятно, есть ли БД как таковая
> :)
> А если я захочу перейти с Oracle на Informix, например,
> то мне не придется менять код клиента и искать аналог ODAC.
>

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

> А я и не писал про логику в СП. СП может заниматься только
> тем, что дергать нужные ХП. Названия и параметры ХП, кстати,
> тоже будут неизвестны злоумышленникам.

Как раз если злоумышленники доберутся до самопального сервера приложений, то уже и ломать ничего не придется. А грамотно построенная на хранимках безопасность даже при знании всех хранимок (а не факт, что их понадобится выносить в общий доступ) и их параметров не даст их выполнить без идентификации пользователя.

> Интерпретирующие же системы всегда проигрывают в производительности
> нативным системам.

В чистом виде - да. Но если начинается активная работа с SQL, то это еще вопрос, что быстрее. Например, перекачка данных отдельными инсертами в пакете выполняется намного быстрее, чем через клиента.

AJAX, DHTML, SOAP, XML-RPC решает указанные роблемы и фактически делает web почти gui приложением

И ради чего такой компот из множества разнородных средств?
Что бы иметь функционал слегка приближающийся с gui?
Стоимость поддержки по сравнению с двузвенкой будет выше.

← →
seg (2006-01-31 10:59) [31]

Не факт, что 3-звенка решит эту проблему. Автоматом точно не решит. ИМХО.

Согласен. Сталкивался с такой 3-х звенкой, вкоторй формы открывались по 15-20 минут!
Запускаешь открытие формы и идешь на обед.
Все дело оказалось в отвратительно спроектированной базе.

ANB © (31.01.06 10:57) [28]

СП добавляет новый уровень безопасности. Безопасность на уровне пользователей никто не отменял. Все, иду работать :)

>
> Игорь Шевченко © (31.01.06 10:54) [25]
Запустить большее количество клиентов без необходимости смены аппаратной платформы

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

DB Link рулит

Это дырка в безопастности.

> СП добавляет новый уровень безопасности. Безопасность на
> уровне пользователей никто не отменял. Все, иду работать
> :)

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

ANB © (31.01.06 11:01) [33]

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

При грамотно написанной трехзвенке - да.

>Игорь Шевченко © (31.01.06 10:54) [25]
>Запустить большее количество клиентов без необходимости смены аппаратной платформы

И что ? Каким боком к этому относится дилемма два/три звена ?

> При грамотно написанной трехзвенке - да.

Ну и если сервер приложений начал тормозить, то чего делать, чтобы быстрее заработал ?

> А если я захочу перейти с Oracle на Informix, например,
> то мне не придется менять код клиента и искать аналог ODAC.

А то, что в любом случае придется переделывать все ХП и апп-сервер - это ничего? Никогда не понимал этого аргумента "легкая смена СУБД". Поднимите руку те, кто разрабатывал трехзвенку на одной СУБД и через некоторое время переписывал с нуля весь апп-сервер и серверную часть ради "легкого переезда на другой сервер". Я хочу просто знать, что такие люди есть и заодно спросить, насколько часто им приходится прыгать между Ораклом, МС СКЛ, Аксессом и тд.

Ситуация, описанная в Reindeer Moss Eater © (31.01.06 10:51) [22] не считается. Если нужна брать данные из качественно разных хранилищ данных, то без промежуточного слоя, который получает эти данные, не обойтись. Не станешь же всем клиентам ставить клиентские части всех использующихся СУБД.

Трехслойка vs Двухслойка Найти похожие ветки