Модераторы: LSD, AntonSaburov

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> целесообразность использования J2EE, J2EE для маленькой фирмы 
:(
    Опции темы
robocoffee
Дата 10.12.2009, 09:31 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 15
Регистрация: 11.9.2009

Репутация: нет
Всего: нет



Здравствуйте, друзья!

есть проект для небольшой фирмы, структура базы данных достаточно сложная, хранится огромное количество данных, но количество пользователей всего 10-20 человек. И работа только в локальной сети. Сложной обработки этих данных не предвидится. Отчеты, автоматическое формирование документов, сравнение данных и т.д. Все, ничего больше. Я решил писать обычное клиентское приложение на Java + MySQL. Без сервера приложений, и без веб-интерфейса. Плюсы я вижу такие: меньше времени на разработку, легкость в установке и поддержке. Минусов пока не вижуsmile

Скажите пожалуйста, какие проблемы могут возникнуть при таком подходе? и есть ли причины для использования j2EE в такой задаче?
PM MAIL   Вверх
jcyber
Дата 10.12.2009, 10:13 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 57
Регистрация: 2.4.2009

Репутация: нет
Всего: нет



Если программа предназначена только для пользования сотрудниками конторы, то нет необходимости поднимать апп. сервер, писать среднее звено и заниматся прочей ерундой. Для такое ситуации вполне подойдет Standalone + JWS.
PM MAIL   Вверх
Nofate
Дата 10.12.2009, 10:13 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 266
Регистрация: 13.10.2008

Репутация: 2
Всего: 8



У нас есть проект для небольших фирм, написанный в виде толстого клиента + mssql. Много таблиц, очень много данных, пользователей пять-десять, документы, отчеты ). И напрягает отсутствие полноценного сервера приложений. Хотя бы банально невозможностью красиво сделать блокировки и обновление данных на всех клиентах. Кроме того пользователи время от времени умудряются работать в устаревшей версии клиента.

Хотя не скрою: проколов в архитектуре хватает. =)

Это сообщение отредактировал(а) Nofate - 10.12.2009, 10:14


--------------------
The future is not set, there is no fate but what we make for ourselves.
Нофейтово пространство и смежные области 
PM MAIL WWW ICQ   Вверх
robocoffee
Дата 10.12.2009, 10:24 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 15
Регистрация: 11.9.2009

Репутация: нет
Всего: нет



Цитата

нет необходимости поднимать апп. сервер, писать среднее звено и заниматся прочей ерундой.

- я примерно также рассуждал, радует что верно мыслилsmile

Цитата

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

- если это единственный минус - то с этим готов смиритьсяsmile

спасибо!
PM MAIL   Вверх
jcyber
Дата 10.12.2009, 10:52 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 57
Регистрация: 2.4.2009

Репутация: нет
Всего: нет



Цитата(Nofate @ 10.12.2009,  10:13)
Хотя бы банально невозможностью красиво сделать блокировки и обновление данных на всех клиентах. Кроме того пользователи время от времени умудряются работать в устаревшей версии клиента.

Обновление данных зависит только от пользователя. Если даже у вас будет сервер с, к примеру, EJB модулем, то на сервер всеравно нужно послать запрос что бы получить обновленные данные из БД, будь то десктоп(нажать на кнопку) или веб-клиент(релоад страницы).
Проблемы со старыми версиями решает JWS.
PM MAIL   Вверх
Vasay
Дата 10.12.2009, 11:07 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



robocoffee

Придерживаюсь мнения, что архитектура толстый клиент <-> DB  - есть моветон.

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

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

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


--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
robocoffee
Дата 10.12.2009, 11:22 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 15
Регистрация: 11.9.2009

Репутация: нет
Всего: нет



Vasay

Цитата

Придерживаюсь мнения, что архитектура толстый клиент <-> DB  - есть моветон.


отлично, а можно пару аргументов в пользу этого? серьезно, буду очень благодарен за конструктивные мысли. Пытался найти какие нибудь статьи на эту тему, но пока - ничего конкретного, везде пишут "решение зависит от задачи".
PM MAIL   Вверх
Vasay
Дата 10.12.2009, 12:01 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



Цитата(robocoffee @  10.12.2009,  11:22 Найти цитируемый пост)
отлично, а можно пару аргументов в пользу этого? серьезно, буду очень благодарен за конструктивные мысли. Пытался найти какие нибудь статьи на эту тему, но пока - ничего конкретного, везде пишут "решение зависит от задачи". 



При архитектуре десктоп приложение <-> база данных возникает проблема  разграничение прав доступа к информации в базе.

Постараюсь привести пример (может быть весьма неудачный)

Есть в фирме 2 менеджера. Они со своего рабочего места должны иметь доступ к информации о своих (и только своих) клиентах. 

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

Вопрос - как разграничить доступ к информации для менеджера 1 и менеджера 2 ?

Получается, что это возможно только внутри клиентской программы при формировании sql запроса. 

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


Ну а если у нас трехзвенная архитектура, то разграничение прав доступа идет на уровне сервера, и менеджер1 не сможет узнать про клиентов менеджера 2 не зная его пароля и логина.  (ну, или не договорившись с администратором базы данных  smile  )

Это сообщение отредактировал(а) Vasay - 10.12.2009, 12:14


--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
robocoffee
Дата 10.12.2009, 12:56 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 15
Регистрация: 11.9.2009

Репутация: нет
Всего: нет



Vasay
кстати да!
сталкивался с этим, ну подумали что не настолько это уж страшно, а менеджер производящий такие действия - настоящий ренегат, таких административными методами вычисляютsmile в общем так и оставили.
спасибо за ваше времяsmile
PM MAIL   Вверх
DimW
Дата 10.12.2009, 14:58 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(Vasay @  10.12.2009,  11:07 Найти цитируемый пост)
Даже делая толстый клиент я бы использовал сервер приложений, как промежуточный уровень.

жжоте! наличие промежуточного уровня уже говорит о том что клиент "тонкий".

Цитата(Vasay @  10.12.2009,  12:01 Найти цитируемый пост)
Есть в фирме 2 менеджера. Они со своего рабочего места должны иметь доступ к информации о своих (и только своих) клиентах.

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

Цитата(Vasay @  10.12.2009,  12:01 Найти цитируемый пост)
то он вполне сможет выдрать строку подключения к базе данных  из программы

это уже говорит о технически не грамотных прогерах.

Цитата(Vasay @  10.12.2009,  12:01 Найти цитируемый пост)
Ну а если у нас трехзвенная архитектура, то разграничение прав доступа идет на уровне сервера,

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

robocoffee, здесь вопрос скорее не в проигреше подхода по каким либо недостаткам технологий, а в целесообразности выбора архитектуры. поверьте в "толстом" клиенте как и в "тонком" достаточно средств которые способны выдержать все требования по разграничению прав доступа, маштабируемости приложения, и т.д.
успехов.
PM MAIL ICQ   Вверх
robocoffee
Дата 10.12.2009, 15:19 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 15
Регистрация: 11.9.2009

Репутация: нет
Всего: нет



DimW

спасибо! можно сказать, вопросов больше нет, ответ полученsmile
PM MAIL   Вверх
Vasay
Дата 10.12.2009, 16:01 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



DimW
Цитата(DimW @  10.12.2009,  14:58 Найти цитируемый пост)
жжоте! наличие промежуточного уровня уже говорит о том что клиент "тонкий".



В моем понимании "тонкий клиент" - это браузер. Любое десктоп приложение - это уже "толстый клиент" и он вовсе не обязан общаться с БД напрямую, общение может происходить, например, и через xml службу.



Цитата(DimW @  10.12.2009,  14:58 Найти цитируемый пост)
для этого существует авторизация. 
ну так вот - после того как менеджер вводит логин пароль, в его текущей сессии инициализируются параметры необходимые для этого самого разграничения клиентов, таким образом передав значения этих параметров в sql зарос и делается это самое разграничение.



Цитата(DimW @  10.12.2009,  14:58 Найти цитируемый пост)
это уже говорит о технически не грамотных прогерах.


И какие возможности предлагает MySQL (о которой шла речь) для разграничения прав доступа? Если мне не изменяет память. максимум что вы можете сделать - это дать ограниченные права на доступ к конкретной базе данных на сервере. 

Но если вы дали пользователю Manager1 возможность делать SELECT из DB_CUSTOMER, то вы не сможете ограничить его возможности селектить любые данные из этой базы данных. (хотя, я могу ошибаться).

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


--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
ivanovpv
Дата 10.12.2009, 16:11 (ссылка) |  (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Варвар
**


Профиль
Группа: Участник
Сообщений: 639
Регистрация: 26.1.2005
Где: Москва

Репутация: 2
Всего: 28



Цитата(DimW @  10.12.2009,  14:58 Найти цитируемый пост)
жжоте! наличие промежуточного уровня уже говорит о том что клиент "тонкий".

Я бы не был таким категоричным... Толщина клиента и наличие сервера приложений вещи из разных опер. Можно иметь тонкого клиента, без сервера приложений, а можно иметь сервер приложений с толстым клиентом.

Сервер приложений нужен не для определения толщины клиента, он нужен либо:
а) Для отделения бизнес-логики от данных и визуализации
или же
б) Для масштабируемости решения

В данном случае, очевидно автор собирается БЛ оставить на стороне гуйного клиента, но поскольку юзеров мало, то тогда зачем ему сервер приложений (не надо масштабируемости, а БЛ все равно на стороне клиента).

Ну а в остальном DimW, я с вами согласен


--------------------
Aut viam inveniam aut faciam
PM MAIL Skype   Вверх
COVD
Дата 10.12.2009, 17:12 (ссылка) |    (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1655
Регистрация: 26.7.2005

Репутация: 4
Всего: 43



Решение вопроса "J2EE - не J2EE"" зависит, на мой взгляд, также от имеющегося опыта. Тем, кто освоил строительство из блоков, врядли будет комфортно класть стены из кирпича. И наоборот. 
Можно начать на той технологии, которая лучше освоена. Если проект не умрет, значит скорее всего будет развиваться. И возможно потребуется смена технологии.
PM MAIL   Вверх
DimW
Дата 10.12.2009, 17:20 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(Vasay @  10.12.2009,  16:01 Найти цитируемый пост)
В моем понимании "тонкий клиент" - это браузер.

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

Цитата(Vasay @  10.12.2009,  16:01 Найти цитируемый пост)
И какие возможности предлагает MySQL (о которой шла речь) для разграничения прав доступа?

вы путаете разграничение прав на объекты БД и с реализацие секюрности приложения.
у мускула как и многих современных БД есть понятие сесси, в которой как и в случае http сессис сервлет контейнера можно организовать инициализацию объекта(в случае с мускулом - инициализацию глобальных переменных) в которых можно хранить параметры авторизованного, посто эти параметры необходимо передавать в sql который должен выполняться с учетом их значений.
ну т.е. если пользователь XXX в системе фигурирует как менеджер компании, то в соответствии с его привелениями приложение должно давать ему доступ только к его клиентам.
примерно так:
Код

select * from clients
 where manager_id = <значение глабальной переменной авторизованного из его сессии БД>


Цитата(ivanovpv @  10.12.2009,  16:11 Найти цитируемый пост)
Можно иметь тонкого клиента, без сервера приложений, а можно иметь сервер приложений с толстым клиентом.

можно хоть один пример тонкого без сервера и толстого с сервером.

Цитата(ivanovpv @  10.12.2009,  16:11 Найти цитируемый пост)
В данном случае, очевидно автор собирается БЛ оставить на стороне гуйного клиента, но поскольку юзеров мало, то тогда зачем ему сервер приложений (не надо масштабируемости, а БЛ все равно на стороне клиента).

в случае с мускулом возможно так и есть, но если взять СУБД такие как oracle, BD2, ms sql, то встроенные языки достаточно эффективны для того что бы реализовывать БЛ именно на стороне БД.

PM MAIL ICQ   Вверх
serger
Дата 10.12.2009, 17:48 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



Цитата(DimW @  10.12.2009,  17:20 Найти цитируемый пост)
в случае с мускулом возможно так и есть, но если взять СУБД такие как oracle, BD2, ms sql, то встроенные языки достаточно эффективны для того что бы реализовывать БЛ именно на стороне БД.

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


--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
Vasay
Дата 10.12.2009, 17:59 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



DimW
Цитата(DimW @  10.12.2009,  17:20 Найти цитируемый пост)
вы путаете разграничение прав на объекты БД и с реализацие секюрности приложения.
у мускула как и многих современных БД есть понятие сесси, в которой как и в случае http сессис сервлет контейнера можно организовать инициализацию объекта(в случае с мускулом - инициализацию глобальных переменных) в которых можно хранить параметры авторизованного, посто эти параметры необходимо передавать в sql который должен выполняться с учетом их значений.
ну т.е. если пользователь XXX в системе фигурирует как менеджер компании, то в соответствии с его привелениями приложение должно давать ему доступ только к его клиентам.
примерно так:


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

берем какую-нибудь тулзу для работы с БД, подключаемся через нее к серверу MySQL, и кто нам запретит выполнить запрос вида 
Код

select * from clients


п.с. Возможно, в новых версиях MySQL и есть варианты защиты, но раньше их точно не было.



--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
DimW
Дата 10.12.2009, 18:04 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(serger @  10.12.2009,  17:48 Найти цитируемый пост)
это хорошо для систем, которые постоянно дорабатываются

назовите хоть одну систему уровня предприятия которая не доробатывается?

Цитата(serger @  10.12.2009,  17:48 Найти цитируемый пост)
для создания впечатления постоянной занятости

имхо это кросплатформенное явление  smile 

Цитата(serger @  10.12.2009,  17:48 Найти цитируемый пост)
это будет требовать постоянного контроля БД

что в вашем понимании "контроль БД"? не уж то администрирование?

Цитата(serger @  10.12.2009,  17:48 Найти цитируемый пост)
наличия грамотного специалиста

а в случае с реализацией БЛ на сервере приложений отсутствие таковых это норма?  smile 

Цитата(serger @  10.12.2009,  17:48 Найти цитируемый пост)
дополнительных ограничений в масштабируемости

и как же БЛ на стороне БД сказывается на маштабируемости приложения? на этот вопрос обязательно ответьте, уж больно интересно стало

Цитата(serger @  10.12.2009,  17:48 Найти цитируемый пост)
мало верю

ваша вера пропорциональна вашему опыту и наблидениям.

Добавлено через 7 минут и 46 секунд
Vasay, вы все верно говорите про то, что в случае с десктопом, овладеть не легальным доступом к БД проще чем в случае с сервером приложений.
вот только я вам не про то толкую, я ведь про разграничение доступа в приложении, а не про наглое овладевание паролем к БД. smile
 
PM MAIL ICQ   Вверх
serger
Дата 10.12.2009, 18:22 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



Цитата(DimW @  10.12.2009,  18:04 Найти цитируемый пост)
и как же БЛ на стороне БД сказывается на маштабируемости приложения?

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


--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
Vasay
Дата 10.12.2009, 18:40 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



Цитата(DimW @  10.12.2009,  18:04 Найти цитируемый пост)

Добавлено через 7 минут и 46 секунд
Vasay, вы все верно говорите про то, что в случае с десктопом, овладеть не легальным доступом к БД проще чем в случае с сервером приложений.
вот только я вам не про то толкую, я ведь про разграничение доступа в приложении, а не про наглое овладевание паролем к БД. smile


DimW
может я изначально не ясно выражался - но я и имел ввиду именно "наглое овладевание паролем".  Который, в случае с десктоп приложением, вполне доступен для "плохого" менеджера, если конечно это приложение общается с БД напрямую, а не через сервер. 

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




Это сообщение отредактировал(а) Vasay - 10.12.2009, 18:45


--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
DimW
Дата 10.12.2009, 18:48 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(serger @  10.12.2009,  18:22 Найти цитируемый пост)
Да банально

так я и думал...

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

Цитата(serger @  10.12.2009,  18:22 Найти цитируемый пост)
единственный способ повышения производительности был - покупка нового сервака.

сомниваюсь, что сторона реализации БЛ, была причиной покупки сервера.

Добавлено через 11 минут и 17 секунд
Цитата(Vasay @  10.12.2009,  18:40 Найти цитируемый пост)
может я изначально не ясно выражался

все ясно было по поводу овладевания паролем - с этим все ясно.

просто помимо этого вы упоменули:
Цитата(Vasay @  10.12.2009,  12:01 Найти цитируемый пост)
Но не будем же мы создавать отдельную БД для каждого менеджера?

в связи с этим я и привел пример как это делать в случае с двухзвенкой.

Цитата(Vasay @  10.12.2009,  18:40 Найти цитируемый пост)
Кроме того трехзвенная архитектура дает много плюсов в сравнении с двухзвенной. 

вобщем то да, я сам двухзвенку на дух не переношу - изжила она себя, в корпоративных маштабах. 
PM MAIL ICQ   Вверх
serger
Дата 10.12.2009, 19:14 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



Цитата(DimW @  10.12.2009,  18:48 Найти цитируемый пост)
serger, маштабируемость и производительность это разные понятия, не вытекающие друг из друга.
маштабируемость - это возможность одновременного доступа к данным, чем больше пользователей могут одновременно использовать один и тот же ресурс тем показатель маштабируемости выше.
производительность  - это показатель за какое время все эти пользователи смогут выполнить тот или иной процесс.


Спасибо за разъяснение - понял. Честно говоря, теперь не совсем понятно, чем же они всё же различаются в реальной жизни? Именно на уровне БД.


--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
Vasay
Дата 10.12.2009, 19:15 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



DimW
Цитата(DimW @  10.12.2009,  18:48 Найти цитируемый пост)
просто помимо этого вы упоменули:
Цитата

Но не будем же мы создавать отдельную БД для каждого менеджера?


в связи с этим я и привел пример как это делать в случае с двухзвенкой.



Это я упомянул, как единственный известный мне способ в MySQL защитить данные второго менеджера от первого, если первый подключается к БД напрямую. а не через программу.

Ну т.е. у каждого менеджера своя БД  со своим паролем и логином smile 

Понятно, что это изврат  smile 


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


--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
v2v
Дата 10.12.2009, 19:47 (ссылка) |    (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1620
Регистрация: 20.9.2006
Где: Киев

Репутация: 9
Всего: 56



Цитата(Vasay @  10.12.2009,  17:59 Найти цитируемый пост)

берем какую-нибудь тулзу для работы с БД, подключаемся через нее к серверу MySQL, и кто нам запретит выполнить запрос вида 
Выделить всёкод SQL

select * from clients


п.с. Возможно, в новых версиях MySQL и есть варианты защиты, но раньше их точно не было.

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

Добавлено @ 19:49
Цитата(Vasay @  10.12.2009,  19:15 Найти цитируемый пост)


Ну т.е. у каждого менеджера своя БД  со своим паролем и логином smile 

Понятно, что это изврат  smile 

зачем своя бд? просто свой логин\пароль. и данные между пользователями не шарятся.

Код

view the_only_one:
select * from client where created_user = :login_user



Это сообщение отредактировал(а) v2v - 10.12.2009, 19:50


--------------------
PM   Вверх
AntonSaburov
Дата 10.12.2009, 21:53 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Штурман
****


Профиль
Группа: Модератор
Сообщений: 5658
Регистрация: 2.7.2002
Где: Санкт-Петербург

Репутация: 8
Всего: 118



Мы решали проблему доступа на уровне БД за счет того, что ВСЕ данные получались/менялись ТОЛЬКО через хранимые процедуры.
По сути слой бизнес-логики был вынесен в БД на уровен хранимых процедур.

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

Как только нужен Интернет-доступ - сразу появится сервер приложений (пусть даже очень просто в виде Томката+Spring).
Правда и в этом случае можно сделать доступ через хранимые процедуры.

PM MAIL WWW ICQ   Вверх
Vasay
Дата 10.12.2009, 21:59 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



v2v

Вы правы есть такая возможность (честно - не знал что в MySQL можно устанавливать права на представления)

Это вариант, хотя и накладывающий некоторые ограничения на работу с БД


--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
DimW
Дата 11.12.2009, 10:22 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(serger @  10.12.2009,  19:14 Найти цитируемый пост)
чем же они всё же различаются в реальной жизни? Именно на уровне БД. 

serger, понимаете, каким бы мега маштабированным приложение не было, маштабированней СУБД оно быть не может, ведь механизмы блокировок, формирования rollback сегментов, кеширования используемых данных, и .т.д. - реализованы в СУБД. Не позволят они приложению повлиять на маштабируемость и производительность в лучшею сторону, только в худшую.

Цитата(Vasay @  10.12.2009,  19:15 Найти цитируемый пост)
масштабируемость в моем понимании

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

Цитата(AntonSaburov @  10.12.2009,  21:53 Найти цитируемый пост)
Правда и в этом случае можно сделать доступ через хранимые процедуры.

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

Это сообщение отредактировал(а) DimW - 11.12.2009, 10:26
PM MAIL ICQ   Вверх
Vasay
Дата 11.12.2009, 10:51 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



Цитата(DimW @  11.12.2009,  10:22 Найти цитируемый пост)
Vasay, ваше понимание и объективная реальность различаются, может стоит не уператься, а раз и навсегда заполнить этот пробел?!



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


Цитата(DimW @  10.12.2009,  18:48 Найти цитируемый пост)
маштабируемость - это возможность одновременного доступа к данным, чем больше пользователей могут одновременно использовать один и тот же ресурс тем показатель маштабируемости выше.




http://ru.wikipedia.org/wiki/%D0%9C%D0%B0%...%81%D1%82%D1%8C

Цитата

Масштаби́руемость (scalability) — в информатике означает способность системы увеличивать свою производительность при добавлении ресурсов (обычно аппаратных). Масштабируемость — важный аспект электронных систем, программных комплексов, баз данных, маршрутизаторов, сетей и т. п., если для них требуется возможность работать под большой нагрузкой. Система называется масштабируемой, если она способна увеличивать производительность пропорционально дополнительным ресурсам. Масштабируемость можно оценить через отношение прироста производительности системы к приросту используемых ей ресурсов. Чем ближе это отношение к единице, тем лучше. Также под масштабируемостью понимается возможность наращивания дополнительных ресурсов без структурных изменений центрального узла системы.


Это сообщение отредактировал(а) Vasay - 11.12.2009, 12:02


--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
DimW
Дата 11.12.2009, 11:15 (ссылка) |    (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(Vasay @  11.12.2009,  10:51 Найти цитируемый пост)
Ну я бы сказал мое понимание понятия "масштабируемости" дальше от объективной реальности чем Ваше  smile  :

да наверное Вы правы, первое не исключает второе, правильный выбор СУБД и грамотная разработка БЛ скорее отсрочит потребность в расширении аппаратной платформы, но ни как не исключит ее расширение при бурном развитии функциональности и числа пользователей приложения.  smile
PM MAIL ICQ   Вверх
serger
Дата 11.12.2009, 11:38 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



Цитата(DimW @  11.12.2009,  11:15 Найти цитируемый пост)
да наверное Вы правы, первое не исключает второе, правильный выбор СУБД и грамотная разработка БЛ скорее отсрочит потребность в расширении аппаратной платформы, но ни как не исключит ее расширение при бурном развитии функциональности и числа пользователей приложения.  smile 


Красиво написано,  smile , 
Мне интересно, как всё-таки как базы "масштабируются" в реальной жизни. Те как увеличить производительность только за счёт увеличения количества "машин".



--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
Vasay
Дата 11.12.2009, 12:13 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73




Цитата(serger @  11.12.2009,  11:38 Найти цитируемый пост)
Мне интересно, как всё-таки как базы "масштабируются" в реальной жизни. Те как увеличить производительность только за счёт увеличения количества "машин".



Большинство современных баз данных позволяют объединить несколько отдельных серверов в кластер.

отсюда
Цитата

Кластер - это объединение нескольких серверов в единую систему. 

Обычно кластерное решение применяют для следующих целей:

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




Справедливости ради стоит заметить, что не только DB  умеют объединятся в кластер но и сервера приложений. 






--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
v2v
Дата 11.12.2009, 12:45 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1620
Регистрация: 20.9.2006
Где: Киев

Репутация: 9
Всего: 56



Цитата(AntonSaburov @  10.12.2009,  21:53 Найти цитируемый пост)
Мы решали проблему доступа на уровне БД за счет того, что ВСЕ данные получались/менялись ТОЛЬКО через хранимые процедуры.
По сути слой бизнес-логики был вынесен в БД на уровен хранимых процедур.

хотел написать про такой вариант, но потом задумался, а на сколько удобно делать выборки через хранимые процедуры?
нда, если бизнес логика реализована и выполняется в процедурах дб то это правильно, удобно и довольно быстро, но что если вернуть надо не 1 или 0, а целую таблицу значений? как это у вас было реализовано?


Цитата(AntonSaburov @  10.12.2009,  21:53 Найти цитируемый пост)

Как только нужен Интернет-доступ - сразу появится сервер приложений (пусть даже очень просто в виде Томката+Spring).
Правда и в этом случае можно сделать доступ через хранимые процедуры.

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


--------------------
PM   Вверх
serger
Дата 11.12.2009, 13:13 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



Цитата(Vasay @  11.12.2009,  12:13 Найти цитируемый пост)
Большинство современных баз данных позволяют объединить несколько отдельных серверов в кластер.

А сами создавали кластера? Меня практика интересует. Точнее впечатления от использования. А не выписки из рекламных брошюр, уж извините.   smile 

Сталкивался со смешанной логикой (часть на хп, основная часть в приложении) - честно говоря она меня напрягла. Много повторений. Не ясность какая-то, что на чём реализовывать и тп.

Добавлено через 6 минут и 26 секунд
Вот, кстати, читаю: NoSQL


--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
Vasay
Дата 11.12.2009, 13:39 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



v2v
AntonSaburov


А как обстоят дела с правами доступа в случае с хранимыми процедурами?

Т.е.  есть процедура, которая селектит данные из таблицы1 и апдейтит таблицу2. Есть пользователь1 у которго есть доступ к процедуре. Должен ли у пользователя1 быть доступ на селект из таблицы1 и апдейт для таблицы2 ? 




serger
Цитата(serger @  11.12.2009,  13:13 Найти цитируемый пост)
А сами создавали кластера? Меня практика интересует. Точнее впечатления от использования. А не выписки из рекламных брошюр, уж извините


Не, сам не создавал smile  Но видел кластер из 3х MS SQL. По заверениям администраторов DB - такая схема обеспечивала прирост производительности по сравнению с одним сервером примерно в 2 раза (но не уверен, что они это сами измерили, в не взяли данные из рекламной брошюры  smile  ). 


--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
v2v
Дата 11.12.2009, 14:00 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1620
Регистрация: 20.9.2006
Где: Киев

Репутация: 9
Всего: 56



Цитата(serger @  11.12.2009,  13:13 Найти цитируемый пост)
Меня практика интересует. Точнее впечатления от использования. А не выписки из рекламных брошюр, уж извините. 

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

Цитата(Vasay @  11.12.2009,  13:39 Найти цитируемый пост)
Т.е.  есть процедура, которая селектит данные из таблицы1 и апдейтит таблицу2. Есть пользователь1 у которго есть доступ к процедуре. Должен ли у пользователя1 быть доступ на селект из таблицы1 и апдейт для таблицы2 ? 

в оракле вроде должен. про mysql боюсь соврать, но тоже наверное должен.

Цитата(serger @  11.12.2009,  13:13 Найти цитируемый пост)
Вот, кстати, читаю: NoSQL 

Цитата

    * горизонтальное масштабирование при больших объемах данных, например как в случае Digg (3 терабайта для зеленых значков, отображаемых, если ваш друг сделал dugg на статье) или Facebook (50 терабайт для поиска по входящим сообщениям) или eBay (2 петабайта в целом)

должен сказать что большинство проблем можно решить правильной архитектурой базы данных, и не нужны никакие NoSQL. Современные реляционные бд с успехом могут справится с указанными объёмами и шустренько работать с ними.


Это сообщение отредактировал(а) v2v - 11.12.2009, 16:56


--------------------
PM   Вверх
serger
Дата 11.12.2009, 14:17 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



Цитата(v2v @  11.12.2009,  14:00 Найти цитируемый пост)
а зря, в какой то мере брошюры отражают суть., и кроме того по ним можно узнать какую именно технологию кластеризации продвигает производитель.
по-поводу практики. да, с помощью кластеризации можно значительно увеличить прирост производительности, путём разнесения разных задач на разные машины кластера. например, пользователи у нас получают доступ к данным с помощью сложных запросов через первую машину, а на второй выполняется постоянное обновление и пересчёт новых входных данных из сети. И пользователи довольны, и обновление работает быстро.

Спасибо.
Нет, ну ПРАВИЛЬНАЯ архитектура решит большинство проблем. Но кто ж её такую делает, да ещё и сразу.. И ещё я всё таки "наивно полагал", что всё-таки система сама должна распределить задачи, между нодами, только успевай их подключать..  smile 


--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
DimW
Дата 11.12.2009, 14:18 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(v2v @  11.12.2009,  12:45 Найти цитируемый пост)
но что если вернуть надо не 1 или 0, а целую таблицу значений? как это у вас было реализовано?

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

Цитата(v2v @  11.12.2009,  12:45 Найти цитируемый пост)
но нужно ли делать лишнюю нагрузку на дб, если есть промежуточный слой который достаточно защищён от клиентов что-бы доверить ему управлять доступом? 

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

Цитата(Vasay @  11.12.2009,  13:39 Найти цитируемый пост)
А как обстоят дела с правами доступа в случае с хранимыми процедурами?

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

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

Это сообщение отредактировал(а) DimW - 11.12.2009, 14:22
PM MAIL ICQ   Вверх
Vasay
Дата 11.12.2009, 15:04 (ссылка) |    (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



Цитата(DimW @  11.12.2009,  14:18 Найти цитируемый пост)
Vasay, вы рассматриваете все немного с нестого ракурса.


А с какого ракурса я должен все рассматривать? Хочу рассматривать 3х и 2х звенную архитектуру с ракурса защиты от несанкционированного доступа. И считаю, что 3х звенка в этом плане предпочтительней. 


Насчет логика в BD против логики в апликэйшен сервере - тут столько факторов, что спорить по этому поводу бессмысленно.

Например:

1. наличие специалистов.
2. стоимость
3. историческая архитектура системы
и т.д.

Кстати, вопрос стоимости весьма интересен - производительность чего выгодней наращивать в конкретной системе - сервера приложений или сервера DB?


--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
DimW
Дата 11.12.2009, 16:26 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(Vasay @  11.12.2009,  13:39 Найти цитируемый пост)
Есть пользователь1 у которго есть доступ к процедуре. Должен ли у пользователя1 быть доступ на селект из таблицы1 и апдейт для таблицы2 ? 

нет, не должен(в случае с оракл).

Цитата(Vasay @  11.12.2009,  15:04 Найти цитируемый пост)
Хочу рассматривать 3х и 2х звенную архитектуру с ракурса защиты от несанкционированного доступа.

шансы одинаковые, если кто то овладел паролем, то ему ни что не мешает миновать все уровни и работать с БД на прямую.
если говорить о возможности овладивания, то да, в случае с двухзвенкой сделать это гараздо проше.
PM MAIL ICQ   Вверх
v2v
Дата 11.12.2009, 16:35 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1620
Регистрация: 20.9.2006
Где: Киев

Репутация: 9
Всего: 56



Цитата(DimW @  11.12.2009,  14:18 Найти цитируемый пост)
если это действительно нужно, то к примеру у оракл есть коллекции, которые могут выступать в качестве OUT параметра, соответственно для их обработки в оракловом jdbc есть возможности.

эх. Вы прокоментировали фразу выдернутую из контекста. Я не утверждаю что нельзя обойтись только ХП, но мне кажеться это совсем не удобным. Для каждого запроса надо написать свою обёртку в виде Хп. В 2 раза больше кода. Но это ещё куда не шло, а представьте что вам надо извлечь 
не 100 записей, а допустим 100К. Одной хваткой вытянуть из базы не удастся, надо реализовывать постраничнкую подкачку: ждбс для запросов предоставляет стандартный понятный механизм, а как быть с процедурами? Опять таки надо накручивать сложную лишнюю логику выборки без которой можна было бы обойтись.
Но я полностью поддерживаю хп подход. Бизнес-логику которая обновляет/удаляет/вставляет записи в более чем одну табличку надо выполнять на уровне хп.

Цитата(serger @  11.12.2009,  14:17 Найти цитируемый пост)
И ещё я всё таки "наивно полагал", что всё-таки система сама должна распределить задачи, между нодами, только успевай их подключать.. 

да, на практике это оказалось не столь эффективно.


--------------------
PM   Вверх
DimW
Дата 11.12.2009, 16:45 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(v2v @  11.12.2009,  16:35 Найти цитируемый пост)
Я не утверждаю что нельзя обойтись только ХП, но мне кажеться это совсем не удобным. 

так я тоже, поэтому я чуть ниже об этом сказал smile
Цитата(DimW @  11.12.2009,  14:18 Найти цитируемый пост)

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




PM MAIL ICQ   Вверх
Vasay
Дата 11.12.2009, 16:51 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



Цитата(DimW @  11.12.2009,  16:26 Найти цитируемый пост)
нет, не должен(в случае с оракл).


Если так, то вместе с возможностью создавать VIEW и назначать права на доступ к ним в теории мы можем обеспечить неплохую защиту данным.


Цитата(DimW @  11.12.2009,  16:26 Найти цитируемый пост)
шансы одинаковые, если кто то овладел паролем, то ему ни что не мешает миновать все уровни и работать с БД на прямую.


Ну, в случае 3х звенной архитектуры сервер с DB может принимать запросы только с ip апликэйшен сервера.
Правда, тут мы имеем другие неприятных моментов связанных с тем, что апп сервер должен иметь доступ ко всей информации с которой он работает, например, нужно не допустить возможность SQL инъекции.

Это сообщение отредактировал(а) Vasay - 11.12.2009, 16:53


--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
serger
Дата 12.12.2009, 09:01 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



Вот видео «Проблемы масштабирования интернет-проектов: когда, как и почему возникают, как с ними бороться».
Там в общих чертах про масштабирование. В принципе почти то что мне хотелось узнать. (мало деталей)
http://javatoday.ru/2009/03/siw-2009-video/


--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
DimW
Дата 14.12.2009, 07:42 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(v2v @  11.12.2009,  16:35 Найти цитируемый пост)
Но я полностью поддерживаю хп подход.

v2v, а вы чистым jdbc пользуетесь или используете какой нить фраймворк для этого.
PM MAIL ICQ   Вверх
DimW
Дата 14.12.2009, 08:57 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(serger @  12.12.2009,  09:01 Найти цитируемый пост)
Вот видео

господа, а с каких пор наличие в приложении асинхронных запросов к апп серв. стало определять его как - "толстое" приожение?
время лекции - [15:50].
досмотрел до середины, на мой взгляд отвратительная лекция, ни о чем...

serger, и чем же скажем вот эта статья, хуже этой гoвнo-лекции?!...

PM MAIL ICQ   Вверх
serger
Дата 14.12.2009, 14:27 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



Цитата(DimW @  14.12.2009,  08:57 Найти цитируемый пост)
serger, и чем же скажем вот эта статья, хуже этой гoвнo-лекции?!...

Ну доклад вводный. Оратор не блеск какой, но мне понравилось. Может многие вещи банальны или спорны, однако от вас я и этого не услышал.  smile 
Кстати, если отбросить рекламную составляющую, а чем она плоха? Ну посоветуйте что нить путное тогда..  smile 



--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
DimW
Дата 14.12.2009, 15:20 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(serger @  14.12.2009,  14:27 Найти цитируемый пост)
а чем она плоха?

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

Цитата(serger @  14.12.2009,  14:27 Найти цитируемый пост)
Ну посоветуйте что нить путное тогда.. 

не могу по советывать ничего в плане расширения аппаратных платформ ибо опыт в этом отсутствует. 

serger, вы пояснить можете, по поводу толщины ПО и ajax, это я туплю?
PM MAIL ICQ   Вверх
serger
Дата 14.12.2009, 15:42 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



Цитата(DimW @  14.12.2009,  15:20 Найти цитируемый пост)
serger, вы пояснить можете, по поводу толщины ПО и ajax, это я туплю? 

Не помню такого, если честно, я ж тоже не всё внимательно слушал..
Ну часто бывает, что докладчики сбиваются и тп., всякое бывает - сам часто такие перлы выдавал!  smile 


--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
Vasay
Дата 14.12.2009, 15:43 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



Цитата(DimW @  14.12.2009,  15:20 Найти цитируемый пост)
serger, вы пояснить можете, по поводу толщины ПО и ajax, это я туплю?



Вопрос по поводу толщины клиента очень спорный.

Если по уму -  тонкий клиент, это приложение не обремененное никакой логикой, кроме логики отображения.


Впринципе, я не видел чтоб JS выполнял какую-либо логику, кроме отображения, ну, может еще валидацию (но в любом случае она должна быть дублирована на стороне сервера).

Другое дело Flash - тут вполне может быть логика не относящаяся к отображению, так браузер загрузивший какое-нибудь flash приложение  уже толстый клиент? Или еще тонкий?

Добавлено через 7 минут и 49 секунд
Хотя если говорить о flash - то браузер тут как бы не причем. Flash может вполне обойтись и без него. 

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


--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
serger
Дата 14.12.2009, 16:04 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



Vasay, ну ваше определение, ИМХО, весьма логично.


--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
DimW
Дата 14.12.2009, 16:23 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(serger @  14.12.2009,  15:42 Найти цитируемый пост)
Не помню такого, если честно, я ж тоже не всё внимательно слушал..

Цитата(DimW @  14.12.2009,  08:57 Найти цитируемый пост)
время лекции - [15:50].


Цитата(Vasay @  14.12.2009,  15:43 Найти цитируемый пост)
Flash может вполне обойтись и без него. 

в прочем как и ява-аплет. видимо действительно, с ajax он перегнул.

ок, понял, спасибо.

Это сообщение отредактировал(а) DimW - 15.12.2009, 09:48
PM MAIL ICQ   Вверх
mbasil
Дата 16.12.2009, 08:42 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 399
Регистрация: 4.5.2007
Где: Москва

Репутация: 9
Всего: 13



 В свое время, в документации по Oracle 9I я прочитал "Режим клиент/сервер устарел". В то время это заявление меня это сильно озадачило. 
Принятие решения об архитектуре приложения вопрос весьма важный. Заказчик говорит - "У нас всегда будет мало клиентов, мы всегда будем работать в локальной сети". Он обманываться рад. Такие прогнозы как правило не оправдываются.
Писать бизнес логику и презентационную логику на ХП, извините меня это решение не только черевато последствиями, но - день вчерашний. БД должна информацию эффективно сохранять и извлекать, а не картинки делать (хотя и может). Попробуйте усложнить такое приложение и выполнить одновременно больше запросов и выяснится, что ваше приложение масштабировать невозможно. Его надо переписывать.
Использование Ajax диктует свои права. Валидация на клиенте запросы с клиента информации и ее обработка. Это, извините, и есть толстый, а иногда и претолстый клиент. Я думаю никого не обманывает эвфемизм "rich".
После нескольких лет работы с JEE и чтения авторизованных курсов SUN по архитектуре распределенных приложений я для себя решил, что ребята из Oracle правы и теперь, при разработке даже небольших приложений я сначала спрашиваю себя - а не сделать ли его Web приложением, даже если сначала и база данных и сервер приложений будут на одной машине. Это конечно первоначально снизит производительность по сравнению с архитектурой клиент/сервер, но потом ...

PM MAIL   Вверх
DimW
Дата 16.12.2009, 10:04 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(mbasil @  16.12.2009,  08:42 Найти цитируемый пост)
черевато последствиями

пример последствий, привести можете?

Цитата(mbasil @  16.12.2009,  08:42 Найти цитируемый пост)
а не сделать ли его Web приложением

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

Цитата(mbasil @  16.12.2009,  08:42 Найти цитируемый пост)
Попробуйте усложнить такое приложение и выполнить одновременно больше запросов и выяснится, что ваше приложение масштабировать невозможно.

странно вы рассуждаете, как будто при использовании веб приложения запросы выполняются вне БД smile 

Цитата(mbasil @  16.12.2009,  08:42 Найти цитируемый пост)
Валидация на клиенте запросы с клиента информации и ее обработка. Это, извините, и есть толстый,

ну давайте подумаем как валидация делает вдруг "клиента толстым "...
по скольку вы реализуете БЛ на аппсерве, то логично бы было валидировать что то на том же уровне, т.е. грубо говоря вы пишете сервлет который лезет в БД, что то там берет, потом э то что то вы анализируете в сервлете и возвращаете в качестве ответа ассинхронного запроса(ajax) true или false. и что же в данном случае делает клиента "толстым"?
PM MAIL ICQ   Вверх
mbasil
Дата 16.12.2009, 10:06 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 399
Регистрация: 4.5.2007
Где: Москва

Репутация: 9
Всего: 13



Лекцию посмотрел после предыдущего сообщения. По-моему зря вы его так сильно, в грязь.
Оратор из него никудышний, конечно. Про пул подключений толком сказать не мог, как будто это всем понятно. От того и вопрос возник, на который он так же невразумительно ответил.
Когда говорил о кэшировании забыл, что на клиенте можно кэшировать помимо куки в объекте JavaScript. По поводу кэширования в базе не знает, что Oracle позволяет кэшировать информацию клиентского сеанса в оперативной памяти. Ясно, что парень работает со специфическими интернет приложениями. Однако дело свое, похоже знает и многие аспекты доклада перекликаются с тем, что предлагает SUN в своих курсах и я с этим согласен.

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

По поводу Ajax еще добавлю. Думаю сам по себе он не обязывает делать толстого клиента, но стимулирует и подталкивает. Еще недавно пуристы JEE говорили - на клиенте только HTML и больше ничего. Я видел недавно одно приложение где всего то была одна страница, а дальше все EXT-GWT. При этом серверная часть только и делала, что пасовала задачи на сервер базы. Крайности всегда отвратительны.

Ну вспомните историю.
- Сначала у нас были ES, которые делали все, а клиент перфокарты или терминал.
- Затем PC и десктоп приложения.
- Потом мы с трудом по капле "выдавливали из себя раба" переходили на клиент/сервер
  (сервер мощный - пусть делает все, вплоть до презентационной логики)
- Потом пришло отрезвление, каким бы мощным не был сервер базы данных, возможности его не безграничны. И мы окунулись в распределенные приложения.
- Сегодня кластеризация и кэширование стало общим местом.
- Что то будет завтра?
 

PM MAIL   Вверх
DimW
Дата 16.12.2009, 10:13 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(mbasil @  16.12.2009,  10:06 Найти цитируемый пост)
По-моему зря вы его так сильно, в грязь.


mbasil, по поводу аратора я не высказывался, просто высказал свое субъективное мнение по поводу полезности лекции.
PM MAIL ICQ   Вверх
mbasil
Дата 16.12.2009, 10:34 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 399
Регистрация: 4.5.2007
Где: Москва

Репутация: 9
Всего: 13



To DimW

Последствия выполнения все на сервере приложений в ХП:
 - Приложение плохо структурировано (мы же говорим о корпоративных приложениях). Вспомните старую книгу Тейта "Горький вкус Java" - она до сих пор актуальна.
 - Сервер базы данных вместо эффективной выборки данных и выполнения DML занимается созданием страниц.

Были у меня на курсе работники одного банка, в котором начальство вдруг решило, что все филиалы должны работать непосредственно на мощном сервере, который они приобрели. Приложение на ХП просто привело к колапсу сервера.
-------
Использовать ХП обязательно надо, но для тех задач, для которых они хорошо подходят. ХП это условно пакетные задачи, которые должны обрабатывать данные непосредственно на сервере базы без пересылки по сети больших объемов и решать специфические задачи. Пример, который считаю характерным - закрытие банковского операционного дня: надо пересчитать остатки по счетам на конец рабочего дня и выполнить ряд других операций за один вызов. Пример отрицательный - один мой слушатель рассказывал, что для разборки больших объемов XML они использовали парсер в виде хранимой процедуры на Java. Результат понятен.
-----------
Валидация и не только. Я уже только что писал свое мнение, что Ajax стимулирует переносить часть обработки информации на клиента - не только обработки презентационной логики (это само собой подразумевается), но и части бизнес логики. А что это, как не толстый клиент. Когда нам говорили "на клиенте - только HTML) я полагал, что это долго не продлится. Тенденция сегодняшняя налицо. SUN даже не переписывает курс по шаблонам JEE, так как мы находимся в переходном периоде: часть шаблонов JEE устарела, а новые неоднозначны.
------
Если бы реализации, использующие Ajax работали только так, как вы это описываете, то разумеется говорить о "толстом" клиенте было бы нельзя. Но сегодня все больше работы переносится на клиента. Одни всем известные фреймворки чего стоят (уже упоминавшиеся мной EXT, GWT, Dojo и т.п). Бросьте, если вам эта тенденция не нравится, это не означает, что ее нет.  

Это сообщение отредактировал(а) mbasil - 16.12.2009, 10:45
PM MAIL   Вверх
mbasil
Дата 16.12.2009, 10:55 (ссылка) |    (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 399
Регистрация: 4.5.2007
Где: Москва

Репутация: 9
Всего: 13



Ну да, в лекции нет технических подробностей, материал преподнесен через призму специалиста, которому ближе Интернет, чем корпоративные приложения, но надо признать - он неплохо очертил необходимость количественного подхода к оценке качества архитектуры распределенных приложений. Мы как разработчики часто забываем о необходимости тестирования под нагрузкой и на репрезентативных данных. Мы больше заботимся о функциональных качествах приложения. Задачи архитектора в другой плоскости. К сожалению в России разделение труда в нашей области плохо  приживается. Я даже горжусь, что я сам себе системный аналитик, архитектор, девелопер, кодер, тестировщик и администратор базы данных. Есть такое подозрение, что я что-то делаю плохо. Психология разработчика плохо вяжется, например с психологией архитектора.  
PM MAIL   Вверх
serger
Дата 16.12.2009, 11:25 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



Цитата(mbasil @  16.12.2009,  10:55 Найти цитируемый пост)
Я даже горжусь, что я сам себе системный аналитик, архитектор, девелопер, кодер, тестировщик и администратор базы данных. Есть такое подозрение, что я что-то делаю плохо. Психология разработчика плохо вяжется, например с психологией архитектора. 

Очень понравилось - постоянно себя приходится в связи с этим изменять в течении дня.


--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
Vasay
Дата 16.12.2009, 11:39 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



mbasil

Спасибо за интересные посты, единственное, я все же не согласился бы с тем что Ajax подталкивает нас делать на JS толстого клиента.  Современные JS/Ajax фрэймворки даже валидацию выполняют на стороне сервера и вряд ли в ближайшее время начнут выполнять какую-либо логику (кроме логики "рисования").




--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
DimW
Дата 16.12.2009, 11:54 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(mbasil @  16.12.2009,  10:34 Найти цитируемый пост)
- Сервер базы данных вместо эффективной выборки данных и выполнения DML занимается созданием страниц.

вы случайно не про oracle HTML DB( или как его сейчас - APEX)?  smile 
mbasil, мы говорим видимо о разных вещах - вы, как можно, а я как нужно.
ведь ни кто насильно не заставляет вас, формирование интерфейсов выносить на уровень БД, пусть этим занимается сервер приложений.
по этому утверждение что ХП это плохо в данном контексте - не верно.

Цитата(mbasil @  16.12.2009,  10:34 Найти цитируемый пост)
Если бы реализации, использующие Ajax работали только так, как вы это описываете, то разумеется говорить о "толстом" клиенте было бы нельзя

да, то что не запрещено,  то можно. smile

Цитата(mbasil @  16.12.2009,  10:55 Найти цитируемый пост)
Я даже горжусь, что я сам себе системный аналитик, архитектор, девелопер, кодер, тестировщик и администратор базы данных.

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

Это сообщение отредактировал(а) DimW - 16.12.2009, 11:57
PM MAIL ICQ   Вверх
mbasil
Дата 16.12.2009, 12:52 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 399
Регистрация: 4.5.2007
Где: Москва

Репутация: 9
Всего: 13



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

To Vasay
Утверждение 
Цитата
Современные JS/Ajax фрэймворки даже валидацию выполняют на стороне сервера и вряд ли в ближайшее время начнут выполнять какую-либо логику (кроме логики "рисования").

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

Когда наш руководитель в силу обстоятельств заставил меня, разработчика,  проводить авторизованные курсы по администрированию Oracle,  я в течении года испытывал непрерывное чувство стыда. Теперь я провожу  курсы по администрированию без особого напряжения, но знаю, что никогда не буду хорошим администратором. А не далее как на прошлой неделе местное подразделение SUN доверило мне прочитать курсы по шаблонам и архитектуре. Так как курсы прошли относительно удачно (клиент в основном доволен), то чего это я должен стыдится? Обстоятельства так сложились.
PM MAIL   Вверх
mbasil
Дата 16.12.2009, 13:17 (ссылка) |    (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 399
Регистрация: 4.5.2007
Где: Москва

Репутация: 9
Всего: 13



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

Это сообщение отредактировал(а) mbasil - 16.12.2009, 13:22
PM MAIL   Вверх
Vasay
Дата 16.12.2009, 13:23 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



mbasil

Цитата

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


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

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

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

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


--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
mbasil
Дата 16.12.2009, 13:56 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 399
Регистрация: 4.5.2007
Где: Москва

Репутация: 9
Всего: 13



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

 
PM MAIL   Вверх
COVD
Дата 16.12.2009, 14:05 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1655
Регистрация: 26.7.2005

Репутация: 4
Всего: 43



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

Цитата

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


Возможность или необходимость быть "многостаночником" делает, на мой взгляд, работу интересной. А мечтой "хорошего" руководителя является налаживание сборочного конвейера. 
PM MAIL   Вверх
mbasil
Дата 16.12.2009, 14:14 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 399
Регистрация: 4.5.2007
Где: Москва

Репутация: 9
Всего: 13



И еще надо добавить нагрузка на приложение в презентационной части увеличивается, так как пользователь избалован Интернетом. Хочу контента и красот ! Просто статические страницы ему недостаточны. Волей неволей появляются новые фреймворки и  Java Script библиотеки, которые обещают много в ответ на возрастающие потребности.  Только не говорите, что эти потребности никогда не коснутся корпоративных приложений.
PM MAIL   Вверх
DimW
Дата 16.12.2009, 15:48 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(mbasil @  16.12.2009,  12:52 Найти цитируемый пост)
Я лишь хотел подчеркнуть, что при разработке современных приложений уровня предприятия (пусть и небольшого) следует соблюдать правильный баланс между назначением узлов и действиями этими узлами выполняемыми - разделение труда должно быть четкое не только между людьми, но и между узлами распределенного приложения.

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

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

PM MAIL ICQ   Вверх
Vasay
Дата 16.12.2009, 16:40 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



mbasil
Цитата

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


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


 
Цитата

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



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

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


--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
mbasil
Дата 16.12.2009, 18:21 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 399
Регистрация: 4.5.2007
Где: Москва

Репутация: 9
Всего: 13



To DimW

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

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

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

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

Это сообщение отредактировал(а) mbasil - 16.12.2009, 18:33
PM MAIL   Вверх
DimW
Дата 17.12.2009, 11:38 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



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

дайте хоть ссылки на то где об этом написано. я тоже могу сказать что приложение можно маштабировать ТОЛЬКО в "ширину" и что? 
Цитата(mbasil @  16.12.2009,  18:21 Найти цитируемый пост)
Сервер базы данных занимается работой, которая для него является побочной
 
побочной  smile, два варианта БЛ:

Код

procedure add_client(p_name in varchar2)
as
begin
  if p_name = 'ИВАН' then
    raise_application_error(-20001, 'ИВАН, не может быть нашим клиентом!');
  end if;
  insert into client (name) values (p_name);  
end;


Код

public class Client
{
    public void addClient(String pName) 
    {
        if (pName.equals("ИВАН"))
        {
           throw new RuntimeException("ИВАН, не может быть нашим клиентом!");
        }
        insertClient(pName);
    }
}    


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

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

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

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

PM MAIL ICQ   Вверх
serger
Дата 17.12.2009, 12:32 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



Цитата(DimW @  17.12.2009,  11:38 Найти цитируемый пост)
ну и как по вашему понять какая реализация побочнее другой для конкретного уровня? да ни как, все относительно.

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


--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
DimW
Дата 17.12.2009, 13:08 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(serger @  17.12.2009,  12:32 Найти цитируемый пост)
Смысл данного примера, аналогичен ощупыванию


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

PM MAIL ICQ   Вверх
mbasil
Дата 17.12.2009, 13:55 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 399
Регистрация: 4.5.2007
Где: Москва

Репутация: 9
Всего: 13



DimW

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

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

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

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

В итоге мы с вами останемся каждый при своем мнении. Не страшно. Главное, что наша перепалка дала пищу для размышления тем, кто только начинает писать и может быть не имеет возможности построить RAC Oracle только для того, что запихнуть на него бизнес логику приложения. Полагаю, что дальнейший обмен колкостями смысла не имеет.
PM MAIL   Вверх
COVD
Дата 17.12.2009, 14:23 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1655
Регистрация: 26.7.2005

Репутация: 4
Всего: 43



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

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

Это сообщение отредактировал(а) COVD - 17.12.2009, 14:28
PM MAIL   Вверх
serger
Дата 17.12.2009, 14:28 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



Цитата(DimW @  17.12.2009,  13:08 Найти цитируемый пост)
serger, вы считаете что этот пример не достаточно сложный для того что бы его рассматривать?
придумайте свой, и попробуйте объяснить себе и нам, где эта грань побочности. 
по каким критериям можно судить о пренадлежности реализации логики на той или иной стороне?  

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


--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
DimW
Дата 17.12.2009, 15:14 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(mbasil @  17.12.2009,  13:55 Найти цитируемый пост)
Полагаю, что дальнейший обмен колкостями смысла не имеет. 

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

по 1.
Цитата(mbasil @  17.12.2009,  13:55 Найти цитируемый пост)
1. Из вашего примера выходит, что вся бизнес логика приложения заключается исключительно в запросах и DML операциях, а также в минимальных проверках.
Очевидно, что таких процедур у вас немного. Впрочем, даже в этом случае есть смысл воспользоваться пакетами.


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

Цитата(mbasil @  17.12.2009,  13:55 Найти цитируемый пост)
Дальше все - россыпь однородных объектов (пакетов). При большом количестве разбирайся, как хочешь. Нет структуры более высокого уровня, а значит она вам не нужна.

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

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

по 3.
Цитата(mbasil @  17.12.2009,  13:55 Найти цитируемый пост)
что информацию надо кэшировать ближе к тому слою, в котором она используется.

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

по 4.
Цитата(mbasil @  17.12.2009,  13:55 Найти цитируемый пост)
4. Мы же говорили о масштабировании. То есть о потенциальном росте нагрузки. Подумайте, что проще кластеризовать, сервер приложений или сервер базы данных и что будет стоить дороже.

mbasil, я ведь не зря на пинок нарывался:
Цитата(DimW @  17.12.2009,  11:38 Найти цитируемый пост)
величив мощности на сервере приложений вы всего лишь позволите большему числу пользователей одновременно воспользоваться API которое добавляет нового клиента, сам же оператор INSERT выполняется на стороне БД, таким образом вся ваша маштабность на одной стороне закончилась, как только обработчик покинул уровень приложения.

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

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

Добавлено через 12 минут и 9 секунд
Цитата(COVD @  17.12.2009,  14:23 Найти цитируемый пост)
удобны тем, что это скрипт: внес изменения - и они сразу вступили в силу после сохранения.

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

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

Цитата(serger @  17.12.2009,  14:28 Найти цитируемый пост)
И отсюда, даже приведя кучу примеров компонентов, мы только в комплексе сможем решить, как лучше реализовать их взаимодействие, что, опять таки, для бизнес-приложений не реально.


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



PM MAIL ICQ   Вверх
DimW
Дата 17.12.2009, 16:14 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



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

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

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

<%@include file="/common/moduleHeader.jsp"%>

        <jdbf:form property="applicationUnit" method="post" action="applicationUnit.jsp">
            <jdbf:canvas title="Модули системы" width="850" height="500">
                <jdbf:connect>

                    <jdbf:group title="Поиск модулей" top="15" left="10" width="830" height="40">
                        <jdbf:split align="left" indent="5" top="9" left="10" width="810">
                            <jdbf:label title="Название:"/>
                            <jdbf:edit property="applicationUnit.name" width="200"/>
                            <jdbf:label title="Адрес (URL):"/>
                            <jdbf:edit property="applicationUnit.url" width="380"/>
                            <jdbf:button property="applicationUnit.find" image="?find?" title="Найти" onclick="doFind"/>
                        </jdbf:split>
                    </jdbf:group>

                    <jdbf:statement property="applicationUnit.stm">
                        <jdbf:query>
                            select id
                                  ,url
                                  ,note
                                  ,name
                              from sys_application_unit t
                             where (:p_name is null or upper(t.name) like upper(:p_name))
                               and (:p_url is null or upper(t.url) like upper(:p_url))
                            order by id desc
                        </jdbf:query>
                        <jdbf:parameter property="p_name" datatype="varchar" value="applicationUnit.name"/>
                        <jdbf:parameter property="p_url" datatype="varchar" value="applicationUnit.url"/>
                    </jdbf:statement>

                    <jdbf:table property="applicationUnit.tbl" statement="applicationUnit.stm" onselectrow="viewDetail" rowcount="11" height="257" width="830" left="10" top="53">
                        <jdbf:column property="id" hidden="yes"/>
                        <jdbf:column property="name" title="Название" width="310"/>
                        <jdbf:column property="url" title="Адрес (URL)" width="500"/>
                        <jdbf:column property="note" hidden="yes" width="310"/>
                    </jdbf:table>

                    <jdbf:label title="Примечание:" left="12" top="320"/>
                    <jdbf:memo property="applicationUnit.note" readonly="yes" top="335" left="10" height="105" width="830"/>

                    <jdbf:split align="right" indent="10" top="450" left="10" width="820">
                        <jdbf:button property="applicationUnit.add" image="?create?" title="Добавить" onclick="doAdd"/>
                        <jdbf:button property="applicationUnit.mod" image="?modify?" title="Редактировать" onclick="doMod"/>
                        <jdbf:button property="applicationUnit.del" image="?delete?" title="Удалить" onclick="doDel"/>
                        <jdbf:button property="applicationUnit.close" image="?close?" title="Закрыть" onclick="doClose"/>
                    </jdbf:split>

                </jdbf:connect>
                <jdbf:error height="70" width="840" top="130" left="5"/>
            </jdbf:canvas>
        </jdbf:form>
        
<%@include file="/common/moduleFooter.jsp"%>


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

<script>
    function doCancel()
    {
        document.applicationUnitMod.action = "applicationUnit.jsp";
        document.applicationUnitMod.submit();
    }

    function doSave()
    {
        if (IsNull(document.getElementById('applicationUnitMod.name')))
        {
            return false;
        }
        if (IsNull(document.getElementById('applicationUnitMod.url')))
        {
            return false;
        }
        document.applicationUnitMod.action = "<%=request.getContextPath()%>/jdbf-admin.sys_pk_security.modify_application_unit.jdbf";
        document.applicationUnitMod.submit();
    }
</script>

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@include file="/common/moduleHeader.jsp"%>

        <jdbf:form property="applicationUnitMod" method="post" action="applicationUnitMod.jsp">
            <jdbf:canvas title="Редактирование модуля системы" width="600" height="320">
                <jdbf:hidden property="applicationUnit.name"/>
                <jdbf:hidden property="applicationUnit.url"/>
                <jdbf:hidden property="applicationUnit.tbl.id"/>
                <jdbf:hidden property="applicationUnit.tbl.property.page"/>


                <jdbf:panel top="10" left="10" height="250" width="580">
                    <jdbf:label title="Название:" top="10" left="12"/>
                    <jdbf:edit property="applicationUnitMod.name" required="yes" top="25" left="10" width="560"/>
                    <jdbf:label title="Адрес (URL):" top="50" left="12"/>
                    <jdbf:edit property="applicationUnitMod.url" required="yes" top="65" left="10" width="560"/>
                    <jdbf:label title="Примечание:" top="90" left="12"/>
                    <jdbf:memo property="applicationUnitMod.note" top="105" left="10" width="560" height="135"/>
                </jdbf:panel>

                <jdbf:split align="right" indent="10" top="269" left="10" width="570">
                    <jdbf:button property="applicationUnitMod.save" image="?save?" title="Сохранить" onclick="doSave"/>
                    <jdbf:button property="applicationUnitMod.cancel" image="?close?" title="Отмена" onclick="doCancel"/>
                </jdbf:split>
                
                <jdbf:error height="70" width="590" top="80" left="5"/>
            </jdbf:canvas>
        </jdbf:form>
        
<%@include file="/common/moduleFooter.jsp"%>


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

<action name="/jdbf-admin.sys_pk_security.modify_application_unit">
   <procedure name="sys_pk_security.modify_application_unit">
        <parameter name="p_name" datatype="varchar" type="in" value="applicationUnitMod.name"/>
            <parameter name="p_url"  datatype="varchar" type="in" value="applicationUnitMod.url"/>
            <parameter name="p_note" datatype="varchar" type="in" value="applicationUnitMod.note"/>
            <parameter name="p_id"   datatype="number"  type="in" value="applicationUnit.tbl.id"/>
   </procedure>
   <forward next="/admin/applicationUnit.jsp" error="/admin/applicationUnitMod.jsp"/>
</action>


и сама ХП:
Код

 procedure modify_application_unit(p_id   in sys_application_unit.id%type
                                  ,p_name in sys_application_unit.name%type
                                  ,p_url  in sys_application_unit.url%type
                                  ,p_note in sys_application_unit.note%type) as
 begin
   update sys_application_unit
      set url = p_url
         ,name = p_name
         ,note = p_note
    where id = p_id;
 end;


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


Присоединённый файл ( Кол-во скачиваний: 21 )
Присоединённый файл  module.jpg 124,13 Kb
PM MAIL ICQ   Вверх
serger
Дата 17.12.2009, 16:18 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



Цитата(DimW @  17.12.2009,  15:14 Найти цитируемый пост)
COVD, serger, согласитесь, что размазывать БЛ по нескольким уровням из за удобства это тоже не есть гуд.

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

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


--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
DimW
Дата 17.12.2009, 16:22 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(serger @  17.12.2009,  16:18 Найти цитируемый пост)
И, кстати, вашу позицию, я как-то до сих пор не могу уловить. 


serger, топиком выше. если будет нужно поясню подробней. 
PM MAIL ICQ   Вверх
COVD
Дата 17.12.2009, 16:45 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1655
Регистрация: 26.7.2005

Репутация: 4
Всего: 43



Цитата

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

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

Цитата

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


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

Это сообщение отредактировал(а) COVD - 17.12.2009, 16:52
PM MAIL   Вверх
mbasil
Дата 17.12.2009, 16:54 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 399
Регистрация: 4.5.2007
Где: Москва

Репутация: 9
Всего: 13



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

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

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

Если представить запросы пользователей как некоторую суету внутри сети из узлов, то при правильно спроектированной сети суета должна уменьшаться с удалением от точки входа. А база данных стоит дальше всего. Ее основное назначение в системе - обеспечивать постоянство, а не суетиться на каждый чих пользователя.
PM MAIL   Вверх
DimW
Дата 18.12.2009, 11:45 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



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


по поводу этого - http://forum.vingrad.ru/index.php?showtopi...t&p=2049640 ничего сказать не хотите? не обязательно, но хотелось бы получить мнение человека который разрабатывал как на уровне БД так и на уровне приложения.
спасибо.
PM MAIL ICQ   Вверх
serger
Дата 18.12.2009, 12:44 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



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


--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
DimW
Дата 18.12.2009, 13:07 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(serger @  18.12.2009,  12:44 Найти цитируемый пост)
очень напоминает систему построения отчётов... 

система на оборот транзакционная, я показал один из модулей этой системы, а именно как эти самые модули я описываю на аппсерве и как осушествляется доступ(вызов) БЛ на стороне БД. 
роли аппсерва в этом случае отводится только доступ к данным и их представлению втом или ином виде пользователю(см. скрин), т.е. пользовательские теги отвечают за генерацию 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
PM MAIL ICQ   Вверх
Vasay
Дата 18.12.2009, 13:17 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



DimW
Цитата(DimW @  17.12.2009,  16:14 Найти цитируемый пост)
1) MVC(в моем случае jsp)


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

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

                            select id
                                  ,url
                                  ,note
                                  ,name
                              from sys_application_unit t
                             where (:p_name is null or upper(t.name) like upper(:p_name))
                               and (:p_url is null or upper(t.url) like upper(:p_url))
                            order by id desc


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

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


--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
serger
Дата 18.12.2009, 13:45 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



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


--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
DimW
Дата 18.12.2009, 14:02 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



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

                   <jdbf:statement property="applicationUnit.stm">
                        <jdbf:query from="представление">
                             <field name="id"/>
                             <field name="url"/>
                             <field name="note"/>
                             <field name="name"/>
                        </jdbf:query>
                        <jdbf:parameter property="p_name" datatype="varchar" value="applicationUnit.name"/>
                        <jdbf:parameter property="p_url" datatype="varchar" value="applicationUnit.url"/>
                    </jdbf:statement>


Цитата(serger @  18.12.2009,  13:45 Найти цитируемый пост)
DimW, а в jsp условия, циклы как реализуются? 

serger, вы имеете ввиду как у меня это реализовано, если да, то ни как, т.е. каждый тег является закончинным компонентом который служит для конкретных целей, все операции по генерации html вынесены в обработчик пользовательского тега.
PM MAIL ICQ   Вверх
serger
Дата 18.12.2009, 14:27 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 518
Регистрация: 19.6.2007
Где: Ижевск

Репутация: 2
Всего: 5



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



--------------------
упс!
PM MAIL WWW Skype GTalk Jabber   Вверх
DimW
Дата 18.12.2009, 14:40 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



Цитата(serger @  18.12.2009,  14:27 Найти цитируемый пост)
А динамические запросы как строятся

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

Цитата(serger @  18.12.2009,  14:27 Найти цитируемый пост)
а видимость элементов HTML как контролируется

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

<jdbf:access name="aceessApplicationUnitAdd">
    <jdbf:button property="applicationUnit.add" image="?create?" title="Добавить" onclick="doAdd"/>
</jdbf:access>

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

Цитата(serger @  18.12.2009,  14:27 Найти цитируемый пост)
Думаю, такое сравнивать бесполезно - время покажет...

надеюсь что я окажусь прав, как и вы. smile
PM MAIL ICQ   Вверх
Vasay
Дата 18.12.2009, 15:23 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2097
Регистрация: 8.3.2006

Репутация: 18
Всего: 73



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


--------------------
Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны.
PM MAIL   Вверх
DimW
Дата 21.12.2009, 08:28 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1330
Регистрация: 24.2.2005
Где: Орёл

Репутация: 3
Всего: 44



всем спасибо, лично для меня данное обсуждение очень полезно.
есть над чем задуматься!!! smile
буду надеяться что я тоже прав, поскольку в ближайшее время пересмотреть архитектуру проекта не реально. 
время покажет smile
PM MAIL ICQ   Вверх
Ответ в темуСоздание новой темы Создание опроса
Правила форума "Java"
LSD   AntonSaburov
powerOn   tux
  • Прежде, чем задать вопрос, прочтите это!
  • Книги по Java собираются здесь.
  • Документация и ресурсы по Java находятся здесь.
  • Используйте теги [code=java][/code] для подсветки кода. Используйтe чекбокс "транслит", если у Вас нет русских шрифтов.
  • Помечайте свой вопрос как решённый, если на него получен ответ. Ссылка "Пометить как решённый" находится над первым постом.
  • Действия модераторов можно обсудить здесь.
  • FAQ раздела лежит здесь.

Если Вам помогли, и атмосфера форума Вам понравилась, то заходите к нам чаще! С уважением, LSD, AntonSaburov, powerOn, tux.

 
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | Java EE (J2EE) и Spring | Следующая тема »


 




[ Время генерации скрипта: 0.3407 ]   [ Использовано запросов: 22 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.