Java EE 中的分层架构答案

【问题标题】：Layered architecture in Java EEJava 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 实体中有很多方法。这不会适得其反吗？

谢谢

【问题讨论】：

标签： architecture jakarta-ee

【解决方案1】：

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

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

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

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

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

【讨论】：

【解决方案2】：

来自Wikipedia：

层和层的概念经常互换使用。然而，一个相当普遍的观点是，确实存在区别，并且层是一种逻辑结构机制构成软件解决方案的元素，而层是系统基础设施的物理结构机制。

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

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

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

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

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

【讨论】：