RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : MySQL или JSP?


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Eugen Kuleshov
To : Pilot
Subj : MySQL или JSP?
> > > В принципе, на перле это делается так же. Обработку данных делают одни функции, представление результатов - другие. Причем и то, и другое - максимально гибкое, поскольку даже HTML относящийся к "оформлению" генерируется динамически и можно использовать разные красивые и удобные трюки. Хотя это не всем нужно конечно. Но тогда можно и PHP обойтись.
> > Брр. perl и php весьма близки по возможностям.
> Не смеши меня. Это все равно как если бы я сказал что Java и PHP близки по возможностям :). Перл - полномасштабный язык программирования и среда разработки, на нем можно писать _абсолютно_ любые программы: развитый стандартный API, доступ ко всем нативным API, горы библиотек с расширениями.

К php тоже есть "горы библиотек"... правда не сравнимые с теми горами которые есть для Java.

> > Java же, в отличие от этих скриптовых языков предоставляет реальные средства для объектно-ориентированного дизайна и разработки приложений. Такие, как например сокрытие информации, наследование и полиморфизм.
> Это все есть в Perl. Perl5 - объектно-ориентированый язык програмирования, весьма развитой. Может ты про перл последний раз слышал лет пять назад - тогда да, это было нечто вроде улучшеной версии awk. Но те времена - уже доисторические.

Ага. Я тут недавно общался с командой, которая ваяет большой проект на перл. Они вообще сказали, что им объекты не нужны. А на мои вопросы об областях видимости пропертей и методов вообще сказали, что они все отовсюду видны и "нужно только договориться" что можно вызывать, а что нельзя. Никаких тебе public, private или protected мемберов. И это тоолько одно...

> > > Неэффективно в чем? Главная проблема
> > Тем, что приложение запускается и прибивается на каждый запрос пользователя.
> На то есть FastCGI и иже с ним (mod_perl). А если http сервер грамотно написан так он вообще это делает совершенно прозрачным образом. Еще раз повторяю - попробуй PW, увидишь что такое _эффективный_ сервер. Апач рядом не валялся, даже с mod_perl.

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

> > Первая проблема которая возникает - куда положить данные, которые хотелось бы сохранить в промежутке между запросами.
> Это как раз весьма изящно делается модулем CGI.pm. В его идеологии - каждая сессия с пользователем - это объект, его можно сериализовать и сохранить - на диске в файл или в базу данных, потом восстановить вместе со всем контекстом. Очень удобно, сам наслаждаюсь.

Ууу... файлики на диске. Крутота. 1000 пользователей - 1000 файликов. Рулез.

> >Кроме того есть некоторые весьма удобные вещи, как, например утилизация конектов к базе данных в запросах. В CGI ты будешь вынужден конектиться каждый раз. Что не есть хорошо для производительности, а на корпоративных системах, ворочающих большими объемами можно натолкнуться еще и на предел одновременных конектов, устанавливаемый SQL сервером (не зря же изобретали 3х уровневую архитектуру).
> Это тоже обходится соотв. расширениями сервера. Опять же, грамотный сервер делает это прозрачно, вообще ничего програмировать не надо. Написаный левой ногой Netscape Enterprise Server с которым мне приходится иметь дело - требует подкручивания и поглаживания, но однако тоже это умеет. Кроме того, для этого есть средства и в DBI.

"Расширение сервера"? Это как, пересобирать весь сервер каждый раз, когда понадобится другое "расширение"?

> > Нет, мне это нарвится. "часть модулей тоже бинарные". Да хоть одна функция будет бинарной и не дай бог не соберется (в Java то bytecode и собирать никуда не надо), то скажи перлу до свидания. :)
> При чем тут bytecode? У перла тоже байткод, ну и что? Речь идет о самом интерпретаторе, или о JVM. Оно естественно должно быть перенесено на систему в бинарном виде. Модули расширения являются частью интепретатора Perl, так что естественно они должны быть собираемы на этой системе. JDBC тоже кстати бинарные по большей части, и это тоже проблема, как я уже писал.

В лучае Java нет требования "собирабельности на этой системе". Знаешь - очень приятно один код и на os/2, и на win32, и на Unix иметь.

> > А JDBC для Oracle еще никто не отменял. :)
> Есть только для WinNT. И экспериментальный lightweight на pure Java. Подозреваю что оно нерабочее. Я же писал уже, ты что текст ответов не читаешь?
> > JDBC
> Нету ни для чего кроме WinNT. DBI есть для всего.

На счет JDBC ты не прав.

> > Я про байткод. Ты не отдаешь исходные тексты. Ничего не надо собирать. А байткод работает везде, где есть JVM, удовлетворяющая спецификации.
> Это да, проблема. Исходники отдавать не хочется. Но вообще-то уже есть компилятор perl в байткод и он уже даже работает. Правда пока это все же бета.

Для Java в бэта-варианте много чего есть. :)

> > Ну знаешь. regexp'ы ему нужны... Взял да написал сам. Один раз. И всем другим дал,
> :-))))))))))
> > чтобы не мучались. Хотя лично я не верю, что нет нормальных regexp'ов. Ту же Cшную либу,
> Ну и не верь на здоровье. Я-то проверял...

Что ты проверял? Что должна такого нетривиального уметь такая "библиотека"? Где ты проверял? И ты так и не сказал зачем тебе regexpы.

> > которой все пользуются (perl в том числе) вполне можно перетащить на Java. Будет один в один, если не лучше даже. :)
> > > Стану, да еще как! Мои коллеги попробовали поставить JVM на свой сервер под CGI, Октан у них там какой-то или еще круче, не помню. Он упал так что они его потом месяц восстанавливали.
> > Уууу... CGI - это абстракция. Это абсолютно ничего конкретного. То есть совсем. Это даже не программа. :)
> Я описАлся. Имелось в виду SGI, Silicon Graphics Inc., это железяки такие, синенькие... Хардверная платформа в общем.

Ну что ж поделать. Надо было думать, когда выбирали серверную платформу. Сейчас чего кулаками то махать. Это примерно из серии - хотеть запустить программу на Visial Age for Smalltalk на Macintosh.

> > Ну еще бы они его не слышали. Этому слову лет 7..8 пожалуй будет. Java - всего 5. А JDBC и того меньше. А учится админам никогда не вредно. Или хотябы научно-популятные журналы читать. :)
> И где ты видел сисадмина читающего научно-популярные журналы? :-))) Они все - с красными глазами и мозолью на заднице :))))

Это проблемы этого сисадмина. Или той конторы где он работает.

> > Слышал я как Нечаев три дня бился головой об стену в попытках собрать mod_perl для осевого Apache. Нафиг, нафиг нам такая
> У меня база с которой я работаю не под осью.

Это к вопросу о переносимости решений на perlе написанных.

> > радость. А ты не смотрел в каком месте твой PersistentCGI хранит результаты меду запросами? Так вот посмотри, порадуйся.
> Рассказал бы, я им как раз не пользуюсь.

Я тоже не пользуюсь. Как и ничем другим, что имеет приставку CGI.

> > FastCGI у меня только нервный смех вызывает. Что, еще есть SlowCGI? :)
> > А как насчет load balancing? N серверов приложений или, скажем K SQL серверов для одного...M httpd.
> Не понял, поподробнее можно? Видимо передо мной такой задачи еще не вставало, а разбираться во всех мыслимых проблемах мироздания я не успеваю :-).

Подробнее так. Любой твой CGI - это своего рода middle слой трех уровневой архитектуры (например веб сервер - CGI - RDBMS SQL). Так вот при некотором пороге кол-ва запросов в единицу времени эти CGI не в состоянии выполняться из-за нехватки ресурсов. Хотя веб сервер вроде и работает. Вот тогда стараются средний слой растащить на несколько серверов приложений.

> > Ты видимо мельком и смотрел раз такие вещи говоришь. Вон Дима Платонов не даст соврать. Или хотябы сходи на сайт java.sun.com и в разделе документации про JDBC там отдельная страница есть, посвященая списку JDBC драйверов для немерянного кол-ва серверов.
>
> Так я же и говорю что - работающего _вообще_ не видел, ни мельком ни как. Вот пусть мне кто видел - расскажет и покажет. А за ссылочку - спасибо, сейчас посмотрю.

И таки он есть!

Mon 03 Dec 2001 18:39 Mozilla/4.7 [en] (WinNT; I)



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.