分层架构

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） 业务层（POJOs + JPA） 集成层（带有休眠DAO） 资源层（HSQLDB）

但是，作为演示文稿，业务和集成层是在同一台服务器上执行的（tomact），我只有三层架构。我对吗 ？

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

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

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

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

感谢

Answer 1

在我的脑海里，“层”是一个合乎逻辑的分离，没有暗示部署拓扑。

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

现在到Entitiy豆。首先，Entity Beans在EJB 3中被替换为JPA - 我们注释对象以控制其持久性。

我认为你有两种业务逻辑，即与客户，订单，员工，发货，学生，课程等各个持久性类的行为有关的业务逻辑，然后是逻辑处于比这个更高的水平，处理这些类的组合。

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

Answer 2

从Wikipedia：

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

基本上，有3个“零件”，以地址：

1. 客户 - 这是介绍情况，并在客户端编程存在（JavaScript）的为您的应用程序的动态交互。

2. 业务 - 这是所有您的业务逻辑存在的地方。算法，领域模型，您的应用程序的“肉”。如果你使用EJB，EJB就住在这里。

3. 数据 - 通常是您从业务层访问的数据库。

您的（不推荐的）实体bean存在于业务层中。但是不要使用JPA，因为它更现代，更简单。

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

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