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

To Vasay
Утверждение 

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

Когда наш руководитель в силу обстоятельств заставил меня, разработчика,  проводить авторизованные курсы по администрированию Oracle,  я в течении года испытывал непрерывное чувство стыда. Теперь я провожу  курсы по администрированию без особого напряжения, но знаю, что никогда не буду хорошим администратором. А не далее как на прошлой неделе местное подразделение SUN доверило мне прочитать курсы по шаблонам и архитектуре. Так как курсы прошли относительно удачно (клиент в основном доволен), то чего это я должен стыдится? Обстоятельства так сложились.

На самом деле то, что мы работаем многостаночниками проблема не наша, а руководителей.  IT специалисты у нас хороши а руководители, увы... Традиция.

Это сообщение отредактировал(а) mbasil - 16.12.2009, 13:22

mbasil, 



Если говорить про Ajax/js, то с распределением нагрузки на клиента я, все же, не согласен

Раньше пользователь получил статичный html и пока он не заполнит формочки, не нажмет кнопку, сервер  ничего не делает. После нажатия кнопки сабмита формы - сервер начинает Валидировать поля, делать какие-то операции с данными, писать их в базу.

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

Т.е. никакого распределения нагрузки нет - логики стало больше, но она осталась на сервере.  

Ну, может я сам себя убедил в этом тезисе.
Недавно "наковырял" для упраженения формочку, где клиент в HTML форме пишет параметры запроса (со всякими там  больше, меньше или LIKE), жмет кнопку, а сервер ему возвращает результаты, которые тут же можно перелистать и исправить, а результаты приходят в виде JSON массива.
Кроме того, я уже говорил, что однажды встретил небольшое приложение, где вся основная работа выполнялась в JavaScript. Мне это откровенно не нравится, но кое-где имеет место. 
А с другой стороны в книгах "Ajax на практике" и "Ajax в действии", в которых рассказывается про использование фреймворка DWR, позволяющего стряпать клиента Web службы на JavaScript. Как вам такой компот, я всегда полагал, что клиент Web службы это прерогатива толстого клиента. Или нет?

 

mbasil,   
(только, наверное, ЕС, а не ES   )



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

И еще надо добавить нагрузка на приложение в презентационной части увеличивается, так как пользователь избалован Интернетом. Хочу контента и красот ! Просто статические страницы ему недостаточны. Волей неволей появляются новые фреймворки и  Java Script библиотеки, которые обещают много в ответ на возрастающие потребности.  Только не говорите, что эти потребности никогда не коснутся корпоративных приложений.

размазано как то получилось, давайте по существу на конкретном примере, если не утамил еще... 
вот я, всю логику реализую на уровне БД которая в свою очередь мапится с конкретным URL на аппсерве, за формирование интерфейса отвечает сервер приложений.
что в данном случае нужно балансировать?
на что стоит обратить внимание?
какие есть потенциальные неприятности в плане потери произвадительности по отношению к ситуации когда БЛ реализована на аппсерве?

mbasil, как вы считаете, почему такой подход вызывает не доверие, боязнь(может быть), не понимание у многих разработчиков? 
ну и вообще есть ли такая проблема, может я параноик?   

mbasil, 


 DWR все же клиент-серверная технология. Логика там остается на стороне сервера. 


 


Интернет то как-раз не балует. Требование соответствия URL контенту делает неприемлемыми, для создания сайтов, большинство фрэймворков.

Так что их создают для корпоративного применения. 

To DimW

При реализации БЛ на сервере приложений ваше приложение легко масштабировать в "ширину" и в "высоту", например добавлением кластеров серверов приложений и балансированием их загрузки. 
При размещении БЛ на сервере базы данных в ХП, при повышении количества пользователей:
- Вы можете масштабировать только в высоту, то есть, грубо говоря только покупкой более мощных машин для сервера базы данных. Сервер базы данных занимается работой, которая для него является побочной. Трудно настраивать на сервере базы данных, какой процент мощности он  должен направлять на выполнение SQL, а какой на выполнение отдельных ХП.
- При усложнении БЛ вам без специальных ухищрений не уследить структурой БЛ.
- Одна из идей EJB заключается в том, что сервер приложений сам следит за загрузкой компонентов и управляет ею по ситуации. См. пул сеансовых компонентов без сохранения состояния и компонентов управляемых сообщениями, а также пассивирование и активирование сеансовых компонентов с сохранением состояния.

Не зря большинство шаблонов проектирования JEE направлено на поддержку четкой структуры приложения. Такой подход делает архитектуру приложения максимально гибкой, все время поддерживая решение потенциальных запросов на рост масштаба. Если приложение не слишком велико и расти не будет - ну и пишите на здоровье с использованием БЛ на ХП. 

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

Я честно говоря "наелся" тех случаев, когда говорят у нас будет 50 пользователей и не больше, база данных будет маленькой, а в Интернет мы никогда не выйдем. И никогда подобные провозглашения будущего не сбываются. Когда-то было время, читая курсы работникам сбербанка заикнулся про web приложение. Они подняли меня на смех - "У нас Интернет киоски, физически отрезанные от основной сети. Мы НИКОГДА не будем работать в глобальной сети." Теперь они усердно пишут  под ВебСферу IBM и усердно изучают Java. Рекомендую еще раз послушать того парня, о котором мы говорили выше. Многое из того, что он говорит по части архитектурных решений перекликается с тем, что рекомендует SUN.  

Это сообщение отредактировал(а) mbasil - 16.12.2009, 18:33

прежде чем буду дальше писать, еще раз напомню свою позицию. я не против ХП, я не против размешения БЛ на сервере приложений.
просто пытаюсь понять почему высказывания в сторону БЛ в БД такие как (ниже) имеют место быть?

дайте хоть ссылки на то где об этом написано. я тоже могу сказать что приложение можно маштабировать ТОЛЬКО в "ширину" и что? 
 
побочной  , два варианта БЛ:





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

возьмем два приложения, которые реализуют БЛ которую я показал выше, каждое на своем уровне.
в каждом из приложений работают 100, пользователей одновременно. 
аппаратные платформы были выбраны с учетом максимального числа пользователей = 200.  
случилось так, что кол-во пользователей в течении недели долно прирости до 1000.
mbasil, что делаем, что расширяем? в одном случае одну сторону в другом другую?   
к чему я клоню: вы считаете, что реализация БЛ на уровне аппсерва даст вам мифическую надежду на простое и разумное расширения платформы(только не надо говорить что вы имели ввиду что то другое). увеличив мощности на сервере приложений вы всего лишь позволите большему числу пользователей одновременно воспользоваться API которое добавляет нового клиента, сам же оператор INSERT выполняется на стороне БД, таким образом вся ваша маштабность на одной стороне закончилась, как только обработчик покинул уровень приложения.
быть может не стоит колотить себя в грудь и декларировать все то что презентует SUN, как не оправержимую истину?!
у оракла тоже много технологий высасанных из пальца(HTML DB, APEX, XSQL), которые он активно продвигает и поддерживает, и ими пользуются, и точно так же в презенташках пишут о выгоде с одного ракурса - удобного для них.

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

и всеравно спасибо за попытку объяснить. 

Смысл данного примера, аналогичен ощупыванию слепцами слона, из известной притчи.    

serger, вы считаете что этот пример не достаточно сложный для того что бы его рассматривать?
придумайте свой, и попробуйте объяснить себе и нам, где эта грань побочности. 
по каким критериям можно судить о пренадлежности реализации логики на той или иной стороне?  

DimW

1. Из вашего примера выходит, что вся бизнес логика приложения заключается исключительно в запросах и DML операциях, а также в минимальных проверках.
Очевидно, что таких процедур у вас немного. Впрочем, даже в этом случае есть смысл воспользоваться пакетами.
Однако PL/SQL пакет, каков бы он ни был хорош (люблю, черт возьми, вместе с разработчиками Oracle использовать PL/SQL пакеты), не предлагает структуры более высокого уровня. Дальше все - россыпь однородных объектов (пакетов). При большом количестве разбирайся, как хочешь. Нет структуры более высокого уровня, а значит она вам не нужна. Поздравляю: либо ваше приложение невелико, либо вы - гений.

2. Отказ от объектного подхода при реализации бизнес логики говорит о том, что она либо очень проста, либо не требует внесения регулярных изменений и дополнений. Вы конечно можете воспользоваться объектными типами PL/SQL, но мы то с вами знаем, что это за бодяга. Вы даже можете писать бизнес логику на сервере на Java. Правда  под каждый класс надо ваять PL/SQL заглушки - Славно придумали ребята !

3. Кроме того, в некоторых приложениях требуется кэшировать информацию сеанса. Есть положение не мной придуманное (не буду опять ссылаться на известно кого, чтобы вас не раздражать), что информацию надо кэшировать ближе к тому слою, в котором она используется. И наверное, при размещении бизнес логики в ХП приходится хранить ее кэш в презентационной части. Что, как следствие, приводит к тесному связыванию бизнес логики с презентационной (tight couple). Более предпочтительным считается подход loose couple. Сами понимаете, почему.

4. Мы же говорили о масштабировании. То есть о потенциальном росте нагрузки. Подумайте, что проще кластеризовать, сервер приложений или сервер базы данных и что будет стоить дороже.

В итоге мы с вами останемся каждый при своем мнении. Не страшно. Главное, что наша перепалка дала пищу для размышления тем, кто только начинает писать и может быть не имеет возможности построить RAC Oracle только для того, что запихнуть на него бизнес логику приложения. Полагаю, что дальнейший обмен колкостями смысла не имеет.

XП (хранимые процедуры) удобны тем, что это скрипт: внес изменения - и они сразу вступили в силу после сохранения. Но редактировать их неудобно. Вот циклы для XП - выглядят "побочными" операцими. Всякие разветвленные if-else тоже. 
А редактировать, например, на Java - удобно. 

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

Это сообщение отредактировал(а) COVD - 17.12.2009, 14:28

Бизнес приложение состоит из большого количества кусочков с разным функционалом, в том числе и таких. Ну и с различной степенью связанности м/у с собой. Я не считаю, что пример плохой, я говорю, что он объясняет только "какой у слона хобот", но соответственно мы не можем из этого примера узнать, какие у слона, например, ноги.
И отсюда, даже приведя кучу примеров компонентов, мы только в комплексе сможем решить, как лучше реализовать их взаимодействие, что, опять таки, для бизнес-приложений не реально.