Java EE 中的分层架构

Posted 2023-04-18

技术标签:

【中文标题】Java EE 中的分层架构【英文标题】：Layered architecture in Java EE 【发布时间】：2011-05-06 13:03:31 【问题描述】：

我有一个一直无法解决的问题：

考虑这两种架构

第一个

UI layer
    |
Application layer
    |
Domain Layer
    |
Infrastructure Layer

第二次

Client Tiers
    |
Presentation Tiers
    |
Business Tiers
    |
Integration Tiers
    |
Resources Tiers

它们之间有什么区别。

实体 bean 在这些架构中的位置。如果我有一个带有实现业务逻辑的对象的业务层，为什么我必须在实体 bean 中添加行为。我在某处读到，拥有没有行为的域模型对象是一种反模式。

谢谢

更新

这实际上是我需要做的一个项目（培训）才能让我的 msc 进入分布式系统。

这些实际上是我正在使用的技术

支柱 2 JPA 数据库数据库

所以如果我理解得很好

我的申请包括

客户端层（网络浏览器）一个表示层（struts 2）业务层（POJOs + JPA）集成层（带有休眠 DAO）一个资源层（HSQLDB）

但由于表示层、业务层和集成层在同一台服务器（tomact）上实现，因此我只有三层架构。我说的对吗？

至于在我的 JPA 对象中包含行为，通常这是我以前做的：每个 JPA 实体都有一个 dao。拥有一个管理所需业务逻辑的 bean（如 EJB）。所以我从不把行为放在 JPA 对象上。

例如，我想提出购买请求。我会有一个 CatalogueManager 来帮助我与项目、供应商进行交互。我还会有一个 EmployeeManager 来帮助我与员工互动。最后是一个 PurchaseRequestManager，它将使用前面的两个业务对象来发出 PurchaseRequest。

现在你要告诉我的是将我在 PurchaseManager 中的方法放入 PurchaseRequest JPA 实体中，并对 EmployeeManager 中的方法执行相同操作 => 将它们放入 Employee JPA 实体中。

但是如果我的员工对象也用于人力资源部门会发生什么，我还需要在那里放置其他方法。对于大型应用程序，我将在员工 JPA 实体中有很多方法。这不会适得其反吗？

谢谢

【问题讨论】：

【参考方案1】：

在我看来，“层”是一种逻辑分离，与部署拓扑无关。

“层”是关于物理部署的。例如，UI 层逻辑可以完全在胖客户端中实现，部署到桌面上的客户端层并且没有单独的表示层，或者可以是基于 Web 2.0 浏览器的应用程序，UI 层分布在 javascript UI 客户端之间服务器中的浏览器和表示层。

现在进入实体豆。首先，实体 Bean 在 EJB 3 中被 JPA 取代 - 我们注释对象以控制它们的持久性。

我认为您有两种业务逻辑，一种与单个持久类的行为有关，例如客户、订单、员工、装运、学生、课程等，然后是它们的逻辑，即在比这更高的层次上，处理这些类的组合。

在我看来，与 Customer 的行为有关的逻辑应该在 Customer 类中。这种行为可能非常微不足道，例如某些类型的验证和总结（例如总订单价值），但它是域逻辑并且可以合理地存在于那些域对象中。所以我们的 JPA 对象有两个角色，实现领域逻辑和通过注释来管理持久性。这些注释的架构状态很有趣，它们实际上是域和基础架构之间的“粘合剂”。

【讨论】：

【参考方案2】：

来自Wikipedia：