模块化java ee应用程序[重复]

Posted 2023-04-18

【中文标题】模块化java ee应用程序[重复]

【英文标题】：Modular java ee application [duplicate]

【发布时间】：2013-03-04 12:02:04

【问题描述】：

我需要重构一个 Java EE 应用程序，因为当前的设计不是非常模块化，实际上它是一团糟。有一个商业门面，但由于该应用程序是由几个人开发的，因此原始设计已被多次忽略。该应用程序当前在带有 JSF 的 tomcat 上运行，但很快将移植到 websphere。我已经对不同的设计模式进行了一些研究，以从视图中封装业务逻辑，以及如何使应用程序模块化，以便更容易为其添加更多功能，因为将来应用程序将得到增强。我读过关于 OSGI 的文章，但我认为那是矫枉过正。

应用程序已被拆分为多个层。但我离定义 API 还很遥远。我已经稍微清理了应用程序。现在所有的 bean 都通过业务外观方法访问业务逻辑。但是业务门面由大约 40 种方法组成，我认为这不是很好。

第三方编辑

例如我有这些模型类

ManageLdap 使用 createAccount 和 deleteAccount 等方法 GroupManager 管理 ldap 组

在业务门面我有一个方法createAccount

调用ManagerLdap 类来创建一个ldap 帐户并 做一些日志记录，还 致电GroupManager

这个伪代码

package Model.ManageLdap

public class ManageLdap 

  public ldapAccount createAccount()   

  public ldapAccount deleteAccount()   


public class GroupManager

  public bool addAccountToGroup(var account)   

在商业门面

package BusinessFacade.Foo

public class SomeFoo

  public ldapAccount createAccount() 
   
    var ldapAccount = new ManageLdap.createAccount();
    Logger.log("Account created");
    var accountWasAdded = GroupManager.addAccountToGroup(ldapAccount);
       

现在，如果我想为应用程序添加其他功能，例如为用户创建 subversion 存储库的选项

我必须实现一个模型类来创建存储库， 在业务门面放一些方法，然后 创建一个额外的 bean 以供视图访问。

这使得立面变得更大更令人困惑，但除此之外，这不是我所说的模块化设计。

那么如何在没有庞大的业务外观的情况下将业务逻辑与视图分离呢？

【问题讨论】：

这已经在 SO 上讨论过很多次了。看看this 和this 等等。

这可能是enterprise-architect 或architecture getting started 的好话题。

@techuser Java Application Architecture Guide 或 Describe the architecture for java web applications 似乎对于解决操作问题来说过于宽泛。在阅读best enterprise shopping cart 之后，我认为查看开源代码，例如BroadleafCommerce 可能是了解如何组织代码的良好开端。

我的伪代码与您描述的相符吗？这对我来说似乎并不坏。您是如何解决重构的？

【参考方案1】：

首先尝试将您的应用程序拆分为多个层，例如：

道 服务 安全性 查看 等

然后从每一层提取一些API（如dao-api、service-api等。每个api模块应该有一组接口）。

然后创建一组模块（如service-api、service-impl、dao-api、dao-impl）并涉及一些构建工具（gradle 或 maven ) 来管理它们。

不允许允许一个实现模块依赖于另一个实现模块（仅 impl -> api 或 api -> api）。

每个模块 - 分隔的 jar 文件。

在这样的重构之后，将来破坏应用程序设计将变得更加困难。

【讨论】：

感谢您的回答，我已经编辑了我原来的问题，希望您能给我一些建议。

如果每个模块都是独立的jar文件，那么部署呢？

您能否详细说明only implementation -> api or api -> api 的意思是否意味着一个实现可以基于多个基于另一个api 的api（api 或api）？