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

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

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

Если программа предназначена только для пользования сотрудниками конторы, то нет необходимости поднимать апп. сервер, писать среднее звено и заниматся прочей ерундой. Для такое ситуации вполне подойдет Standalone + JWS.

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

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

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

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


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

спасибо!

Обновление данных зависит только от пользователя. Если даже у вас будет сервер с, к примеру, EJB модулем, то на сервер всеравно нужно послать запрос что бы получить обновленные данные из БД, будь то десктоп(нажать на кнопку) или веб-клиент(релоад страницы).
Проблемы со старыми версиями решает JWS.

robocoffee, 

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

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

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

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

Vasay, 



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

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

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

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

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

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

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

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


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

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

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

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


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


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


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

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

DimW, 

спасибо! можно сказать, вопросов больше нет, ответ получен

DimW, 



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








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

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

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

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

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

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

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

Решение вопроса "J2EE - не J2EE"" зависит, на мой взгляд, также от имеющегося опыта. Тем, кто освоил строительство из блоков, врядли будет комфортно класть стены из кирпича. И наоборот. 
Можно начать на той технологии, которая лучше освоена. Если проект не умрет, значит скорее всего будет развиваться. И возможно потребуется смена технологии.

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


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



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


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