я бы согласился с вами, но не могу сдержаться, прокоментирую некоторые ваши реплики. такое чувство что вы даже не попытались сделать шаг к тому что понять меня. :(

по 1.


да, не следует этого из моего примера, это общий случай, в 90% БЛ это манипуляция данными с учетом правил, которые накладывает бизнес процесс. и обсолютно не важно, простая валидация используется или сложная, простой DML, или сподвывертом, два DML оператора или один. в конце концов это не важно, для конечного использования бизнес единицы, пусть это будет процедура, пусть она будет в пакете, пусть это метод в классе на другом уровне. 


пакет->процедуры(функции) - однородные объекты   
класс->методы - ну пипец какое разнообразие   
если нет четкого описания бизнес действие ---> объект_исполнитель(не важно какого уровня), то надеятся на успешный проект не стоит.
к счастью такие средства(CASE) есть.

по 2.
опять вы про то как "можно"...

по 3.

ну так ничего и не мешает, кеширование результата, на БЛ оказывать влияние не может, так что нужно кеширование- реализовывайте, не нужно так не нужно...

по 4.

mbasil, я ведь не зря на пинок нарывался:

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

если у вас еще осталось желание, то прошу прокомментировать 4 пункт, прав я или нет.
спасибо.

Добавлено через 12 минут и 9 секунд

и тем самым "разваливает" все зависипые объекты, и все сессис из пула твердят что "состояние пакетов было сброшено" 




COVD, serger, согласитесь, что размазывать БЛ по нескольким уровням из за удобства это тоже не есть гуд.

to all: 
вы занаете, я наверное сам виноват в вашем недопонимании, я не привел ни одного примера, как я вижу разработку веб приложений с использованием ХП.

рассмотрим один из модулей системы, которую я разрабатываю и поддерживаю.
скрин модуля в приложенном файле.

и так:
1) MVC(в моем случае jsp)


затем сама формачка в которой редактируются значения:


затем мапинг MVC с ХП по адресу - /jdbf-admin.sys_pk_security.modify_application_unit.jdbf (функция яваскрипт doSave())


и сама ХП:


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


Присоединённый файл ( Кол-во скачиваний: 21 )
 module.jpg 124,13 Kb

очень провокационная фраза.. Еле сдерживаюсь...   

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

serger, топиком выше. если будет нужно поясню подробней. 

И не надо "размазывать". Если на серверной стороне кроме базы данных есть более высокий слой, то пресловутая бизнессссс логика должна быть там. А в хранимых процедурах - специфические, внутренние для базы данных операции, которые не относятся к БЛ.   



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

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

Многое зависит от типа вашей системы. Это транзакционная (OLTP) система или система больше ориентированная на получение и просмотр информации (Dcision Support System). 
Я полагаю, что бизнес логика даже в случае OLTP поровну содержит запросы и DML предложения. Причем выполнение DML предложения проще (без учета сложности управления транзакциями), чем работа с разнообразными запросами, которые в том числе требуют и того или иного кэширования результатов на сервере приложений. Не забывайте, что если вы используете JPA, например с Hibernate, то контекст постоянства также является кэшем первого уровня. 

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

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

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

mbasil, спасибо, в принцыпе все понятно.
видимо мне просто все это еще предстоит переварить, но зная себя - пока не споткнусь не пойму(не поверю).
было бы проще если бы я на данный момент не имел опыта, был начинающим программистом, но блин мы в четыре рыла(+ 8-10 аналитиков по 1-2 человека на предметрую область) поддерживали систему(толстую) которая охватывала все предметные обрасти предприятия, была сложнейшая логика написанная на pl/sql, работа была организованна таким образом что это было делать просто. 
сейчас поддерживаем систему (веб) с одной предметной областью, гемороя огребаем по самые нехочу... наследие индусов...   
невольно возникает вопрос, так в чем же проблема в архитектуре или в организации труда(подходе, отношении к своему делу)!?


по поводу этого - http://forum.vingrad.ru/index.php?showtopi...t&p=2049640 ничего сказать не хотите? не обязательно, но хотелось бы получить мнение человека который разрабатывал как на уровне БД так и на уровне приложения.
спасибо.

DimW, очень напоминает систему построения отчётов...

система на оборот транзакционная, я показал один из модулей этой системы, а именно как эти самые модули я описываю на аппсерве и как осушествляется доступ(вызов) БЛ на стороне БД. 
роли аппсерва в этом случае отводится только доступ к данным и их представлению втом или ином виде пользователю(см. скрин), т.е. пользовательские теги отвечают за генерацию html, а доступ к БЛ в БД мапируется для конкретного урла. 
в данном случае ХП -  sys_pk_security.modify_application_unit доступна по урлу - "<%=request.getContextPath()%>/jdbf-admin.sys_pk_security.modify_application_unit.jdbf", который представлен ввиде экшена - /jdbf-admin.sys_pk_security.modify_application_unit.

Это сообщение отредактировал(а) DimW - 18.12.2009, 13:08

DimW, 


А где MVC? (jsp не может быть - MVC, jsp предназначен для  "View")

Я вижу только что-то похожее на "View", в котором что-то делает 


который должен быть в "Model", а не посреди тэгов отвечающих за рисование интерфейса. 

Это сообщение отредактировал(а) Vasay - 18.12.2009, 13:20

DimW, а в jsp условия, циклы как реализуются?

Vasay, в данном случае jsp представлено как MV, не спорю что это криво, в ближайшее время планируется вынемти это недоразумение за пределы jsp, в свое оправдание могу объяснить это как издержки неопытности, в то время когда этот тег реализовывался  
будет примерно так:



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

А динамические запросы как строятся, а видимость элементов HTML как контролируется?
В общем, всё равно не до конца понятно. Сомневаюсь, что сможете на пальцах раскрыть детали. Трудно воспринимается, так как ОЧЕНЬ уж все непривычно.   
Думаю, такое сравнивать бесполезно - время покажет... 

их попросту нет.


путем выдачи определенных приверегий пользователю системы
к примеру кнопка:

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


надеюсь что я окажусь прав, как и вы. 

DimW, 


Может я просто не понял Вашу идею, но как-то мне не нравится :-(


Я бы сделал так:

(Снизу вверх, упрощенная версия )

классы сущностный (Entity) - pojo классы для представления данных из DB в программе.

классы доступа к данным (DAO) - в этих классах осуществляется вся работа с бд. Т.е. есть у Вас класс UnitDAO, у него есть методы:
getUnitList(.....) - возвращает список Unit , может иметь несколько реализаций (без параметров - весь список, с параметрами типа max и first)
getUnitById(long id)  
deliteUnitById(long id)
saveUnit(Unit unit)
.... и тд - вообщем все операции, которые Вам могут потребоваться.

Есть контроллер, конкретная реализация будет зависеть от фрэймворка и конкретной задачи.
Например, для стандартных CRUD операций можно сделать  UnitController c методами 
list() 
show()
edit()
delite()
create()
save() 

соответственно, определенный метод вызывается в соответствии с определенным URL (например, можно формировать url таким образом: http://site.com/unit/list?max=10&first=20 - мы просим вызвать метод list() UnitController-а и говорим - покажи 10 результатов начиная с 20-го)

UnitController запрашивает в UnitDAO метод getUnitList(10,20); получает список из 10 Unit-ов (в упрощенном варианте, в реальном приложении желательно иметь промежуточный класс) и скармливает его шаблонизатору (шаблонизатор - тот же jsp, velocity, freemarker....)


Это сообщение отредактировал(а) Vasay - 18.12.2009, 15:47