Swing rich client в многоуровневом контексте

Question

Мы находимся на этапе анализа / раннего проектирования будущего приложения Swing, где постоянство обеспечивается базой данных (вероятно, альтернатива между Oracle и mySql в зависимости от денег клиента).

По сути, приложениебудет иметь два вида модулей:

• Одна подсистема "admin" для подачи и обслуживания набора ссылочных данных;
• X других подсистем, использующих подмножества этих данных и создающих свои собственные объекты(в деловом смысле), ссылаясь на элементы этих подмножеств.

Мои вопросы:

1. Я полагаю, что лучшая практика - ограничивать только развертываемое приложение Swingчтобы представить вопросы и сделать его запросом бизнес-уровня на удаленном сервере, это «более глубокое» приложение является единственным, имеющим доступ к базе данных и отвечающим за вопросы сохранения.Существуют ли причины, по которым мы могли бы пойти другим путем и позволить приложениям Swing напрямую взаимодействовать с БД (отрицая необходимость отдельного бизнес-уровня)?Какие аргументы я могу привести, чтобы поддержать архитектуру бизнес-уровня для техников в процессе принятия решений?
2. Существуют ли какие-либо соображения по проектированию (структуры, шаблоны, условные обозначения кода), которые вы бы посоветовали для такого типа решения (расширенный клиент в многоуровневом контексте)?
3. Существуют ли инструменты, которые могут помочь нам на этапе кодирования, особенно для извлечения ссылочных поднаборов данных в приложение Swing, управления их кешем и проверки целостности (проверки того, что измененные объекты приложения Swing отправляются обратно вБД не заменяет другие модификации, представленные с момента получения)?

Answer 1

Я ни в коем случае не эксперт в этом, но у меня есть некоторые мысли, которые могут быть полезны.
1) Стандартная практика - разделять код, который обрабатывает уровень представления, с кодом, который обрабатывает бизнес-логику. Платформа Swing сама обеспечивает это через шаблон MVC. Сказав это, почему вы думаете об удаленном сервере, взаимодействующем с БД? Это, безусловно, вариант, но вы должны учитывать различные задержки в сети. Вас волнует, например, как быстро обновляется графический интерфейс? Вы можете создать презентацию, то есть спроектировать и структурировать свой проект так, чтобы у вас был слой (отдельный от уровня презентации), взаимодействующий с БД, которая является локальной, а не удаленным сервером. В вашем вопросе относительно аргументов нетехнических людей я предполагаю использовать удаленный сервер. Если вы считаете, что он должен быть удаленным, вы можете представить преимущества разделения, производительности и общего дизайна.
2) Если вы хотите иметь удаленный бизнес-уровень, вы можете использовать веб-сервисы. Хотя это должно быть удаленным?

Answer 2

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

3-уровневая архитектура (клиент Swing, сервер приложений, сервер базы данных) может быть полезной, если применяется одна из следующих причин:

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

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

3. Если сложно развернуть новую версию клиентского программного обеспечения на каждом рабочем столе.В 3-уровневой архитектуре 50–70% ошибок можно исправить, просто развернув новую версию на сервере приложений.

Если вам нужно перейти на 3-архитектура уровня, вы, вероятно, захотите взглянуть на Java EE (Java Enterprise Edition) и на серверы приложений, реализующие его (JBoss, GlassFish, WebLogic и т. д.).Существует много литературы о лучших практиках Java EE.Но учтите, что Java EE сложна и имеет крутую кривую обучения.

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

Answer 3

Это звучит как приложение, созданное для реализации веб-сервисов.Ваш интерфейс вызывает веб-сервис для получения данных или возвращает данные для сохранения.Бизнес-уровень работает на сервере и отвечает за упаковку данных для клиентов.

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

Вы также можете объяснить, что тестирование будет прощекодирование станет проще, а добавление функций в будущем станет проще и понятнее.

\ 2.и 3. Сайт apache.org уже имеет множество функциональных возможностей, уже готовых к использованию (когда вы быстро освоите его использование.) Ознакомьтесь с группами проектов Jakarta и Web Services.