architecture - Java EE 中的分层架构

Question

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

考虑这两种架构

第一

UI layer
    |
Application layer
    |
Domain Layer
    |
Infrastructure Layer

第二

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

它们有什么区别。

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

谢谢

更新

这实际上是我需要做的一个项目(培训)，以便在分布式系统中获得我的 MSC。

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

Struts 2 日本专业协会 HSQLDB

如果我理解得好的话

我的申请包括

客户端层(网络浏览器) 表示层(struts 2) 业务层(POJO + JPA) 集成层(带有 hibernate DAO) 资源层(HSQLDB)

但是由于表示层、业务层和集成层是在同一台服务器(tomact)上实现的，所以我只有三层架构。我说得对吗？

就在我的 JPA 对象中包含行为而言，我通常这样做: 每个 JPA 实体都有一个 dao。 有一个 bean(如 EJB)来管理所需的业务逻辑。所以我从来没有把 Beahvior 放在 JPA 对象上。

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

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

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

谢谢

Answer 1

在我看来，“层”是一种逻辑分离，不暗示部署拓扑。

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

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

我认为你有两种业务逻辑，一种与单个持久类的行为有关，例如客户、订单、员工、发货、学生、类(class)或其他什么，然后它们的逻辑是在比这更高的层次上，处理这些类的组合。

在我看来，与客户行为有关的逻辑应该位于客户类中，这似乎是合理的。这种行为可能非常微不足道，例如某些类型的验证和汇总(例如总订单值(value))，但它是域逻辑，并且可以合理地存在于这些域对象中。因此，我们的 JPA 对象有两个角色，实现域逻辑并通过其注释管理持久性。这些注释的架构状态很有趣，它们实际上是域和基础设施之间的“粘合剂”。