一个同时支持在线和离线使用的应用程序，分层的好策略是什么？

Question

一个同时支持在线和离线使用的应用程序，分层的好策略是什么？

4

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

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

我的计划如下。

1）创建DAO库（JPA）

将我的DAO（当前为JDBC）切换为使用Java持久性API。这样，我就可以在桌面应用程序上开始使用RDBMS，如derby、sql express或类似的东西，并重用实体和DAO代码来执行所有的db操作。我可以将此打包成一个类库，并在Web和桌面上使用相同的库。

2）创建业务逻辑库

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

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

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

如果您对实现此目标有任何建议，对我开始这个项目有任何警告或任何可能帮助我的框架，请让我知道。

- Allan

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Pascal Thivent · Accepted Answer

一个既可以在线使用，又可以离线使用的应用程序分层的好策略是什么？

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

以下是一些额外的说明：

我会选择在桌面上使用完整的Java数据库（derby），这样更容易管理其生命周期。
Spring将提供良好的整体支持（用于分层，用于声明式事务管理）。
JPA不提供任何合并或数据库的设施，您将不得不自己实现并处理痛苦的事情，比如冲突的更改等。

¹ 我甚至会考虑跳过DAO，直接从服务层访问JPA的EntityManager。有些人可能不同意这种做法，但事实是EntityManager已经实现了Domain Store模式，它几乎可以完成DAO模式的所有工作，并且在DAO后面进行保护并没有太多价值。