为可以在线和离线使用的应用程序分离层的好策略是什么？

Question

我有一个 Java Web 应用程序，它有一个“断开连接”的 Java Swing 桌面应用程序。使用桌面应用程序用户连接到互联网并从服务器下载他们需要的数据。他们可以断开连接并离线使用应用程序。当他们重新连接到互联网时，他们可以将数据同步回服务器。

服务器本身是一个 Java EE Web 应用程序，而桌面应用程序是该 Web 应用程序的有限功能版本。到目前为止，所有业务逻辑和数据访问代码都是为每个应用程序单独编码的。每个应用程序的数据存储都不同（Web 是 SQL Server，Desktop 是序列化对象）。一些新的要求涉及到两个应用程序的大量开发。由于功能相同，我想将数据访问代码和业务逻辑分层，以便我可以轻松地为两个应用程序重用它。

我的计划是做以下事情。

1) 创建 DAO 库 (JPA)

切换我的 DAO（当前为 JDBC）以使用 Java Persistence API。通过这种方式，我可以开始在桌面应用程序（如 derby、sql express 或类似的东西）上使用 RDBMS，并重用实体和 DAO 代码来执行所有数据库操作。我可以将它捆绑到一个类库中，并将同一个库用于 Web 和桌面。

2) 为业务逻辑创建库

Web 应用程序是用 struts 2 编写的。我将在我的 Action 类中使用所有逻辑，但它在 POJO 中。使用业务逻辑创建一个 jar 类库。我可以将 lib 添加到我的 Web 和桌面项目中。然后我可以从我的 struts 操作和我的桌面应用程序中调用 POJO。

我假设 JPA 将负责复制数据访问代码并将业务逻辑（大部分是 dao 调用）放在单独的库中将负责复制业务逻辑。

所以我的问题是：对于可以在线和离线使用的应用程序，分离层的好策略是什么？

如果您对以不同方式实现此目标有任何建议，请在我开始此项目时对我提出任何警告或任何可能对我有帮助的框架，请告诉我。

Answer 1

对于可以在线和离线使用的应用程序，分离层的好策略是什么？

嗯，从高层次的角度来看，您的计划看起来不错，并且肯定会简化您的应用程序的维护。我没有太多要补充的：创建 JPA 实体、一个服务层，如果您觉得需要，还可以创建一个 DAO 层¹。然后在您的两个应用程序中使用这些部分，并使用不同的 JPA 设置。

以下是一些附加说明：

• 我会选择桌面上的完整 Java 数据库 (derby)，这样会更容易管理其生命周期。
• Spring 将提供良好的整体支持（对于分层，对于 declarative transaction management）。
• JPA 没有为合并或数据库提供任何工具，您必须自己实现它并处理诸如冲突更改等痛苦的事情。

¹ 实际上，我什至会考虑跳过 DAO 并直接从服务层访问 JPA 的 EntityManager。有些人可能不同意这一点，但事实是 EntityManager 已经实现了 Domain Store 模式，它几乎完成了 DAO 模式所做的工作，并且在 DAO 后面屏蔽它并没有太大价值。