对于可以在线和离线使用的应用程序来说,分层的好策略是什么?

发布于 2024-09-13 21:52:06 字数 869 浏览 13 评论 0原文

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

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

我的计划是执行以下操作。

1) 创建 DAO 库 (JPA)

将我的 DAO(当前为 JDBC)切换为使用 Java Persistence API。这样我就可以开始在桌面应用程序上使用 RDBMS,例如 derby、sqlexpress 或类似的东西,并重用实体和 DAO 代码来执行所有数据库操作。我可以将其捆绑到一个类库中,并在网络和桌面上使用相同的库。

2) 创建业务逻辑库

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

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

所以我的问题是:对于可以在线和离线使用的应用程序来说,分层的好策略是什么?

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

I have a Java web application that has a 'disconnected' Java Swing desktop app. Using the desktop app users connect to the internet and download data they need from a server. They can disconnect and use the application offline. When they reconnect to the internet they can sync their data back to the server.

The server itself is a Java EE web application and the desktop app is a limited functionality version of the web app. Up until now all business logic and data access code was coded separately for each application. The data stores were different for each application (Web is SQL Server and Desktop is Serialized objects). Some new requirements involve a lot of development to both applications. Since the functionality is the same I want to layer the data access code and business logic so I can easily reuse it for both applications.

My plan is to do the following.

1) Create a DAO library (JPA)

Switch my DAOs (currently JDBC) to use Java Persistence API. This way I can start using a RDBMS on the desktop app like derby, sql express or something similar and reuse the entites and DAO code to do all of the db operations. I can bundle this into a class library and use the same library for the web and the desktop.

2) Create a library for business logic

The web app is written in struts 2. I will take all of the logic in my Action classes and but it in POJOs. Create a jar class library with the business logic. I can add the lib to my web and desktop project. Then I can call the POJOs from my struts actions and from my desktop application.

I assume that the JPA will take care of duplicating the data access code and putting the business logic (which for the most part are dao calls) in a separate library will take care of duplicating the business logic.

So my question is: What is a good strategy for separating layers for an application that can be used online and offline?

If you have any recommendations for achieving this differently, any warning for me as I begin this project or any frameworks that might help me please let me know.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

待天淡蓝洁白时 2024-09-20 21:52:06

对于可在线和离线使用的应用程序来说,分层的好策略是什么?

好吧,从高层的角度来看,您的计划看起来不错,并且肯定会简化应用程序的维护。我没有太多要添加的内容:创建 JPA 实体、服务层,如果您觉得需要,还可以创建 DAO 层1。然后在两个应用程序中使用这些部分,并使用不同的 JPA 设置。

这里有一些附加说明:

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

1 我什至会考虑跳过 DAO 并访问 JPA直接来自服务层的EntityManager。有些人可能不同意这一点,但事实是 EntityManager 已经实现了 Domain Store 模式的作用与 DAO 模式的作用几乎相同,并且将其屏蔽在 DAO 后面没有太大价值。

What is a good strategy for separating layers for an application that can be used online and offline?

Well, your plan looks decent from a high-level point of view and will definitely simplify the maintenance of your applications. I don't have much to add: create JPA entities, a service layer, and if you feel the need, a DAO layer1. Then use these parts in both of your applications, with different JPA settings.

Here are a few additional notes:

  • I would go for a full Java database on the desktop (derby), it will be easier to manage its lifecycle.
  • Spring would provide good overall support (for layering, for declarative transaction management).
  • JPA doesn't provide any facility for the merge or databases, you'll have to implement that yourself and handle painful things like conflicting changes, etc.

1 I would actually even consider skipping the DAOs and accessing JPA's EntityManager directly from the service layer. Some people might not agree with this but the fact is that the EntityManager already implements the Domain Store pattern which does pretty much what the DAO pattern does and and there is not much value at shielding it behind a DAO.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文