java - 这个项目结构有效吗？

Question

我有一个难题:在大学里我们学习创建模块化软件(在 java 上)，但是这种模块化是使用带有包的单个项目来解释的(一个用于业务的包，另一个用于 DAOS，另一个用于模型，哦，最后一个前端包)。

但在我的工作中我们使用下一个结构:

我会尽力解释:

首先我们创建一个 java 库项目，其中模型(实体类)是在一个包中创建的。

接下来我们创建一个名为 DAOS 的 EJB，并使用 netbeans 向导将 DAOS 接口(interface)存储在另一个包中的库项目中，这些接口(interface)在 DAOS bean 中实现。

所以下一部分是业务逻辑，我们为每组功能创建一个业务 EJB，再次使用向导我们将接口(interface)存储在另一个包中的 java 库项目中，然后在业务 bean 上实现。

最后一部分(对于后端)是我建议的一个 bean:一个 Facade bean，它将在单个 bean 中收集业务 bean 的每个方法，并且它也有一个在我们的库项目中创建并实现的接口(interface)在 bean 里。

所以接下来的部分是在 web 项目上调用 facade 模块。

但我不知道这有多有效或可行，也许我做错了一切，我什至不知道!所以我想问问你对此的看法。

Answer 1

在模型工程中存放DAOS、BusinessBeans、Facade的接口(interface)并不是一个好的选择。

反对意见:

1. 数据结构(实体类)、业务逻辑(BusinessRemote、FacadeRemote)和技术逻辑(DAOSRemote)混合在一个项目中。它们在不同的包装中，但将在一个 jar 中交付。
   • 在其他应用程序中重复使用数据结构将导致您的项目中出现新应用程序不需要的类。
2. 其中一个界面的更改将强制重建您的项目。如果由于新的需求或特性需要更改外观接口(interface)，则必须更改模型项目中的接口(interface)类。这将导致您的项目需要分发一个新的 jar。

建议:

• 分离实现和接口(interface)是一个好方法；但一路走下去。创建单独的接口(interface)项目(业务、门面、DAOS)。如果您正在使用一些依赖管理工具(Maven、Ivy 等)，您将只向该接口(interface)项目添加依赖项。对于您的 WAR，您将单独包含所有 jar。

好点:

• 添加一个额外的接口(interface)作为应用程序外观是好的。我们使用这种方法为不同的用户角色提供不同的应用程序外观，而不会将这种角色逻辑混合到我们的业务逻辑中。