Опять, 25... Я Вас умоляю...

ГрымзДля построения интерфейса интранет-системы (т.е. системы, в которой мы можем выдвигать определённые требования и ограничения в адрес аппаратно-программной платформы клиентского рабочего места) можно использовать как старые добрые технологии активного содержимого (типа java applets или, не к ночи будь помянуты, ActiveX), так и всякие новомодные прибамбахи типа ajax и flash.

Что java applets, что "всякие новомодные прибамбахи" сильно подымают требования "в адрес аппаратно-программной платформы клиентского рабочего места" по сравнению с обычным толстым win32 клиентом. Миф №1...

Грымз3. А какие такие у 3-звенки особенные сложности, перекрывающие её достоинства?

3 звена, вместо 2х! Еще сложности нужны?! Миф №2...

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

Гм... Вот у нас классическая 2у звенка. Выложили новую версию на сервак - и "все пользователи автоматически начали с ней работать". Третье звено, как и пятое колесо, тут совершенно не нужно. Миф №3...

ГрымзНет проблем с организацией работы с системой территориально распределённых пользователей - хоть из соседнего здания, хоть с другого конца земного шара. Как выше было уже сказано - это очень ценно для логистической конторы. Выдали экспедитору мобильник и PDA - вот рабочее место и готово, сел на пенёк на опушке - и набивай себе информацию.

Да я хоть с Нижней Тегусегальпы могу работать - был бы хоть какой-нибуь канал связи. Миф №4...

ГрымзВ общем, если требования разработчика по срокам и деньгам заказчика устраивают - IMHO не надо заморачиваться насчёт архитектуры системы, пусть делают под тонкий клиент

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

ГрымзПравда? Читаем system requirements для Flash Player 8:

Intel Pentium II 450MHz or faster processor (or equivalent)
128MB of RAM

Много ли Вы видели за последний год офисных компьютеров, не отвечающих этим требованиям?

Уважаемый, я думаю, Вам не надо объяснять, чем отличются minimum system requirements и те requirements, на которых Ваше приложение, использующее "всякие новомодные прибамбахи" будет работать без тормозов, т.е. иметь нормальное время отклика, например, на элементарный скрол по гриду. На приведенной Вами конфигурации толстый клиент, написанный, скажем, на Delphi, будет летать, а вот упомянутые Вами java applets, и "всякие новомодные прибамбахи" буду жутко тормозить. Проверено...

ГрымзА у собаки 4 ноги. А у кенгуру 2. И что - из этого следует, что у собаки в жизни больше сложностей, чем у кенгуру?

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

ГрымзТрёхзвенка - это отделение бизнес-логики от client view, т.е. (навскидку-первое что в голову приходит):


Заменяем в Вашем высказывании одно слово:

Двузвенка - это отделение бизнес-логики от client view, т.е. (навскидку-первое что в голову приходит):

и пытаемся подставить Ваши же аргументы:

Грымз1. Перенос "тяжёлых" операций с чахлого клиента на мощный сервер

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

Грымз2. Лёгкая миграция данных между различными database backends и предоставление клиенту прозрачного доступа к распределенным хранилищам данных

С миграцией, действительно, не все так гладко. А вот на счет "предоставление клиенту прозрачного доступа к распределенным хранилищам данных" - да.

Грымз3. Возможность значительного изменения бизнес-логики без внесения изменений в клиентскую часть

Да.

Грымз4. Лёгкость создания data marts корпоративной БД для различных структурных подразделений.

Да.

Если еще, что-то "придет в голову" на предмет плюсов 3х звенки - пишите. Я и многие остальные участники форума (и не только этого его раздела) ждем их уже давным давно.

ГрымзДа много чего ещё вкусного.

Гы... Читайте Выше...

ГрымзУмные люди трёхзвенку ведь не для собственного удовольствия придумали, а для удовлетворения потребностей бизнесов.

Вот и надо исходить из "потребностей бизнеса", а не из кажущихся Вам "вкусностей".

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

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

ГрымзАга. Особенно прикольно это всё выглядит, когда человек 500 с началом рабочего дня практически одновременно пытаются запустить лежащий на серваке набор программулин мегабайта в два-три весом каждая. Наблюдали-с.

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

ГрымзПравда чтоль? Не могли бы Вы выложить куда-нибудь демо-версию толстого клиента своей ИС? Очень хочется позапускать её одновременно на PDA под WinCE через GPRS, линуховом компе в интернет-кафе и ноутом под Вистой в вайфайном хот-споте.

Все, на чем может работать Win32 будет работать.

ГрымзP.S. Вообще на самом деле спор беспредметен без знания требований заказчика к обеспечению удалённого доступа к системе и характеристик компьютерного парка и линий связи.

Вот здесь, позволю себе с Вами согласиться.

Bogdanov AndreyБизнес-логика не реализуется средствами SQL - необходимо использовать процедурные языки.

О-па... А мужики то и не знают... ((с) Реклама пива).

Bogdanov AndreyПроцедурные расширения большинства СУБД не являются объектно-ориентированными. А ООП языки - удобнее, особенно в больших проектах и позволяют луше структурировать код и тем самым снизить его сложность

Разрешите заметить, что речь идет о системах, расчитанных на обработку данных. И, уж если, данные храняться в реляционной СУБД, то я не вижу никакой необходимости в каком-либо ООП языке, дополнительном к процедурным расширениям конкртеной СУБД. Быстрее, чем на SQL, обрабатывать реляционные данные на другом языке не получится.

Bogdanov Andrey(не зря же сейчас практически все СУБД начинают к себе Java или что-то такое привинчивать).

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

Bogdanov AndreyИли вы ярый противник ООП программирования?

На клиенте - 2мя руками за. На стороне сервера, где реализуется бизнес-логика на SQL "ярый противник".

NonsensДелал как внутрикорпоративные, так и коммерческие коробочные продукты в трехзвенке. Ничего такого, чем тут пугают, замечено не было.

М.б. огласите некоторые из "коробочных"?!

Bogdanov AndreyЗамечу, что речи о скорости обработки данных не было. Вопрос исключительно о сложности разработки. так что давайте не отступать от темы.

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

Что понадобиться мне:

1. Одна хп на сервере, которая принимая в качестве параметров id позиции штатного расписания и процент изменения выполняла бы один элементарный UPDATE.
2. Один компонет на клиенте, который бы в нужный момент подставлял параметры и "дергал" бы эту процедуру.

Теперь прошу Вас описать как бы это выглядело при Вашем подходе.

Bogdanov AndreyТо есть вы признаете, что ООП - позволяет снизить сложность приложений.

Я признаю одно -"Кесареву - кесарево". Т.е. инструмент должен применяться к месту, а не использоваться только из догматических соображений.

Bogdanov AndreyНо вера (или другие соображения - сейчас мы их не касаемся, так как речь исключительно о сложности) не позволяет вам использовать SQL на стороне сервера.

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

Bogdanov AndreyНу так что ж. Вы вправе усложнять себе жизнь, но не надо пугать этими сложностями других.

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

Nonsens pkarklin NonsensДелал как внутрикорпоративные, так и коммерческие коробочные продукты в трехзвенке. Ничего такого, чем тут пугают, замечено не было.

М.б. огласите некоторые из "коробочных"?!

Удостоверяющий центр

Этот? http://www.infotecs.ru/Soft/uc.htm#2