AlexG
Ни одно из этих условий не говорит ни "за", ни "против" трехзвенки. Совершенно никакой разницы.

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

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

Просто как пример - с год назад здесь кто-то просил оценить свежесделанный сайт. Я пошел туда, и за пару минут поймал его на SQL Injection - в смысле, прочитал содержимое sysobjects.... править это содержимое не стал :)) Если бы наружу торчал голый сервер - мне таки пришлось бы подбирать пароль.

Отдельный вопрос - ok, допустим есть плохо защищенный сервер, и его надо спрятать. Это задача транспортного уровня, протокола - например, обычный vpn либо собственная реализация того же подхода, вплоть до весьма изощренной. Трехзвенка здесь присутствует чисто номинально; приложения, пользующиеся, например, BDE, куда более "трехзвенны" по своей архитектуре.

рубльтем более, что при таком раскладе установки клиентских частей СУБД ненужно.
Хм. А зачем она нужна в двухзвенке? Мешает - не ставьте, нет проблем.

рубльможно канечно VPN но это уже тонким клиентом не назовеш.
Хм. Да в общем-то в двухзвенке тонкого клиента вообще особо не предусмотрено :)

Давайте чуть определимся. Я не слишком согласен с привычкой многих обзывать практически любое веб-приложение трехзвенкой. Почему: потому что браузер в нем выполняет примерно ту же функцию, которую в обычном клиент-сервере выполняет драйвер монитора в операционке. Да, наличие достаточно сложного канала между "клиентским приложением" и "экраном" - отдельный вариант, о котором надо думать. Но - я могу подключить свой терминал к любому X-серверу; я могу зайти на другую машину RAdmin-ом, Remote Desktop-ом, VNC - приложение, запущенное на "той" машине и доступное мне через точно такой же "длинный" канал от того не становится трехзвенным.

SarinХм. Что уж тогда и говорить про ADO и уж тем более ODBC.
ADO - весьма вероятно, но я не настолько в курсе его возможностей, чтобы уверенно говорить. Скажем, позволяет ли оно делать гетерогенные запросы? Что касается ODBC - не вижу причин так считать, как раз тупой "буфер между".

рубльПросто скажу что мне нравится.
Аплет-сервлет-БД, самое незамысловатое собрание в катором сервлет попрасту буфер между аплетом и БД. Привлекает то, что для разворачивания рабочего места ненужно больших знаний и усилий. Иногда это бывает очень полездно. Опять же иногда.
В разворачивании архитектура особого значения не имеет, скорее возможности платформы.

Впрочем, в любом случае для разворачивания в принципе достаточно одного клика - скачать и запустить программу (setup, initiator итп). Для апплета будет проблема с java-машиной и jre, для экзешника - с операционкой; примерно одно и то же.

Мне такая архитектура нравится именно в варианте трехзвенки; в возможности иметь логику на сервере (в частности, избежать передачи по сети больших объемов обрабатываемых разнородных данных), и в то же время клиент, в котором можно нормально работать (jsp-интерфейс, видимо, будет предусмотрен для подключения с мобильников и прочих извращений).

рубльВот это я имел в виду когда говорил о работе в локалке и глобальной сети.
С этой точки зрения аргумент экстраглобальный - он останется верным и для чистого интранета, и в то же время далеко не всегда будет определяющим. Что я, собственно, и имел в виду, говоря "надо смотреть".

Впрочем, стоит также отметить, что если, допустим, "тупой буферный сервлет" получает на вход текст select-а и возвращает апплету rmi-шный ResultSet - это собственно и является близким вариантом собственной реализации vnp, только малость непрозрачным (хотя можно сделать и полностью прозрачным, если зарегистрировать в апплете соответствующий jdbc-драйвер).

SarinТвоя моя не понимать. ADO с ODBC - не полноценное третье звено (а в случае ADO даж четвёртое, может). Это прокладка, которая, фактически, делает проект многозвенным, даже если тебе это нафиг не надо.
Именно что. Парой писем выше я написал, что не вижу причин рассматривать тривиальные прокладки как "звенья", тем более что если начать их считать, выйдет десяток-другой в любом приложении. В частности, я не вижу причин рассматривать браузер как "звено", а не как особый вид терминала.

SarinС точки зрения проектирования ты прав. А с точки зрения скорости? Что быстрее будет ODBC с ADO, или сокет? Думаю ответ вполне очевиден.
Мне - так он совершенно не очевиден. Точнее, я знаю, что ADO делает внутри себя кучу ненужного, и поэтому имею основания предполагать, что будет заметно и зря тормозить. Насчет ODBC - не в курсе.

Но прежде всего я не совсем понимаю противопоставления. Допустим, я работаю через сокет с сервером БД. Допустим, я работаю через сокет с некоторой самописной хренью, которая уже работает с сервером БД. Что будет быстрее? Ответ столь же очевиден.

P.S. "Очевиден" для меня - это "если написано хорошо, работает быстро; если написано плохо, тормозит".

SarinБраузер - именно что звено. Между сервером и юзером:)
Таких звеньев в любом приложении можно насчитать десяток-другой. Включая кактус.