Question

我有一个我从未能够解决的问题：

考虑这两种架构

第一

UI layer
    |
Application layer
    |
Domain Layer
    |
Infrastructure Layer

第二

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

他们之间有什么区别。

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

由于

更新

这实际上是我需要做的一个项目（培训），以便在分布式系统中获取我的msc。

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

Struts 2 JPA HSQLDB

所以如果我理解的话

我的申请包括

客户端层（网络浏览器）演示层（struts 2）业务层（POJO + JPA）集成层（使用hibernate DAO）资源层（HSQLDB）

但是由于演示，业务和集成层是在同一台服务器（tomact）上实现的，所以我只有三层架构。我是对的吗？

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

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

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

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

感谢

Answer 1

在我看来，“图层”是一种逻辑分离，不会影响部署拓扑。

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

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

我认为你有两种业务逻辑，它关注个人持久类的行为，如客户，订单，员工，发货，学生，课程或其他什么，然后他们的逻辑是在某个更高级别，处理这些类的组合。

对我而言，关注客户行为的逻辑应该属于客户类，这似乎是合理的。这种行为可能非常简单，例如某些类型的验证和摘要（例如总订单价值），但它是域逻辑，可以合理地存在于那些域对象中。因此，我们的JPA对象有两个角色，即实现域逻辑，并通过其注释来管理持久性。这些注释的架构状态很有趣，它们实际上是域和基础架构之间的“粘合剂”。

Answer 2

来自Wikipedia：

层和层的概念通常可互换使用。然而，一个相当普遍的观点是确实有一个差异，并且图层是逻辑结构化机制构成软件解决方案的元素，而层是一个系统基础设施的物理结构机制。

基本上，有3个“部分”要解决：

客户端 - 这是演示文稿发生的地方，以及客户端编程存在的地方（Javascript），用于与您的应用程序进行动态交互。
业务 - 这是您所有业务逻辑所在的位置。算法，领域模型，应用程序的“肉”。如果你使用它们，EJB就会存在这里。
数据 - 通常是您从业务层访问的数据库。

您的（已弃用的）实体bean存在于业务层中。但是不要使用，然后使用JPA，因为它更现代，更不麻烦。

您也可以将JPA实体用于业务逻辑，因为它们非常“轻量级”，因此不需要完全分离。

为了简单起见，不要过度使用“架构”，“设计模式”，“企业模式”或其他任何听起来过于企业化的东西。

Java EE中的分层体系结构

2 个答案: