Какова хорошая стратегия для разделения слоев для приложения, которое можно использовать онлайн и офлайн?

Question

У меня есть веб-приложение Java, которое имеет «отключенное» настольное приложение Java Swing.Используя настольное приложение, пользователи подключаются к Интернету и загружают необходимые данные с сервера.Они могут отключить и использовать приложение в автономном режиме.При повторном подключении к Интернету они могут синхронизировать свои данные обратно на сервер.

Сам сервер является веб-приложением Java EE, а приложение для настольных компьютеров является версией веб-приложения с ограниченной функциональностью.До сих пор вся бизнес-логика и код доступа к данным кодировались отдельно для каждого приложения.Хранилища данных были разными для каждого приложения (Web - это SQL Server, а Desktop - это сериализованные объекты).Некоторые новые требования предполагают большую разработку обоих приложений.Поскольку функциональность одинакова, я хочу наложить код доступа к данным и бизнес-логику, чтобы я мог легко использовать его для обоих приложений.

Я планирую сделать следующее.

1) Создать библиотеку DAO (JPA)

Переключить мои DAO (в настоящее время JDBC) на использование API персистентности Java.Таким образом, я могу начать использовать СУБД в настольном приложении, таком как derby, sql express или что-то подобное, и повторно использовать entites и код DAO для выполнения всех операций с БД.Я могу связать это в библиотеку классов и использовать одну и ту же библиотеку для Интернета и рабочего стола.

2) Создать библиотеку для бизнес-логики

Веб-приложение написано в стойках 2. Iвозьму всю логику в моих классах Action и, кроме того, в POJO.Создайте библиотеку jar-классов с бизнес-логикой.Я могу добавить библиотеку в свой веб и настольный проект.Затем я могу вызывать POJO из своих действий в Struts и из моего настольного приложения.

Я предполагаю, что JPA позаботится о дублировании кода доступа к данным и введении бизнес-логики (которые по большей части являются вызовами dao) в отдельной библиотеке позаботится о дублировании бизнес-логики.

Поэтому мой вопрос: какова хорошая стратегия разделения слоев для приложения, которое можно использовать в сети и в автономном режиме?

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

Answer 1

Какова хорошая стратегия разделения слоев для приложения, которое можно использовать онлайн и офлайн?

Что ж, ваш план выглядит достойно с точки зрения высокого уровня и определенно упростит обслуживание ваших приложений. Мне нечего добавить: создать сущности JPA, сервисный слой и, если вам это нужно, слой DAO ¹ . Затем используйте эти части в обоих ваших приложениях с различными настройками JPA.

Вот несколько дополнительных заметок:

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

¹ Я бы даже подумал о том, чтобы пропустить DAO и получить доступ к JPA EntityManager непосредственно с сервисного уровня. Некоторые люди могут не согласиться с этим, но факт в том, что EntityManager уже реализует шаблон Domain Store , который в значительной степени выполняет то же, что и шаблон DAO, и нет особой ценности в его защите за DAO .