java - (Entity-Control-Boundary pattern) -> 如何处理两个实体？

Question

前提

我最近阅读/观看了 Java Champion Adam Bien 的很多文章/视频，他在其中提倡使用 ancient 但更新 Entity - Control - Boundary设计模式 JAVA EE >= 6.

利用 CDI、EJB 3.1、JPA 2 和其他 JAVA EE 6 功能，此模式应该有助于创建更多面向业务的组件、更易于单元测试并具有更高的关注点分离度基于职责。

由于我正在使用上面列出的所有功能，而且这种模式听起来很有趣，所以我正在研究它，看看 ECB 是否能满足我的下一个项目要求。

到目前为止我得到了什么

在 ECB 中，每个逻辑实体分为三部分(如果我错了，请纠正我):

• 一个边界，一种强大的外观，是唯一可以从外部访问的类。对于外部(如果我没记错的话)，我们指的是应用程序外部，例如。一个远程客户端，在组件包之外，例如。我申请的另一部分；

• a(n optional) Controller，负责某种操作(例如，Entity的验证)；

• 实体，可以是纯 JPA 实体，但也可以包含一些装饰/验证/(最小)业务内部逻辑。

例如，考虑有两个不同的实体(Orange 和 Apple)，一个对它们执行 CRUD 的类(FruitsManager)和一个类对它们执行一些控制 (FruitsQualityChecker)。

直到昨天，它会是这样的(OLD WAY):

com.foo.bar.business.FruitsService        /* CRUD    */
com.foo.bar.business.FruitsQualityChecker /* CONTROL */
com.foo.bar.model.Orange                  /* ENTITY  */
com.foo.bar.model.Apple                   /* ENTITY  */

在欧洲央行，我会(新方式):

com.foo.bar.business.oranges.boundary.Oranges       /* CRUD    */ 
com.foo.bar.business.oranges.control.QualityChecker /* CONTROL */
com.foo.bar.business.oranges.entity.Orange          /* ENTITY  */

com.foo.bar.business.apples.boundary.Apples         /* CRUD    */
com.foo.bar.business.apples.control.QualityChecker  /* CONTROL */
com.foo.bar.business.apples.entity.Apple            /* ENTITY  */

然后我可以 CRUD 并单独研究每个实体，例如。与

Oranges.findOrangesByPrice(min, max);

主要问题

我应该如何处理跨组件研究，例如 findFruitsByPrice(min,max)？

我是否应该同时调用 findOrangesByPrice 和 findApplesByPrice 并对结果求和？来自哪个类，打包在哪里？ 如果我的搜索页面有很多条件，必须跨越 50 个实体怎么办？运行每个实体的搜索方法 50 次，然后执行插值，听起来是一种非常丑陋的方式，对性能影响巨大。我想我仍然需要某个地方的中心点来执行此类操作。它应该是另一个组件，例如称为搜索，在其边界调用其他边界？这一点对我的 ATM 来说是模糊的。

附带问题

将 ECB 与基于行动的框架一起使用是否有意义？还是这种模式属于基于组件的框架？

我使用的是 Struts2，它是一个基于 MVC 操作的框架，我对 JSF2(JAVA EE 6 标准，在 Adam Bien 的大部分展示中使用)非常不熟悉，它是一个基于 MVC 组件的框架；

除了考虑架构“组件方式”的额外努力之外，还有什么阻止我在业务层上使用 ECB 吗？

由于 Adam Bien 示例中的大部分边界都是 REST 服务(通常更像是 Struts2 Actions 的替代品，而不是 “链条中的新齿轮”)，这让我怀疑它可能是 < em>完全适用于 Struts2 生态系统。

说出你的。请。

Answer 1

就我对设计模式的理解而言，您对“到目前为止”的理解是正确的。

关于您的主要问题:与其他设计模式一样，您可以简单地引入另一个用于某些端点的 SuperComponent(或单个 SuperComponent，这样它就不会变得非常大)。 SuperComponent 将以正确的方式做事:如果需要，您将使用一些现有的组件，这样性能和代码质量就不会受到影响。我在这里的意思是:您可能会编写与特定端点相关的逻辑，不关心它是否返回橘子和苹果，对数据库进行单个查询(如果您的域模型能够做到这一点)。使用其他组件来获取这些水果并将它们合并是一个糟糕的设计，无论您使用什么设计模式(图像您稍后将获得鳄梨，然后您将不得不编写代码/纠正错误以获得对新水果)。

现在以某种方式与您的附带问题相关(恕我直言): ECB 适用于小型项目，但对于大型项目，您可能需要更多层次的结构:

• 一个 Web 层，它只处理来自用户的请求/输入(我不喜欢我的 EJB 知道 HttpRequest 和 HttpResponse s)

• 一个多层应用程序模型，带有一个 DAO 层(对于 CRUD 操作不是强制性的，但对于您在多个 EJB 中使用具有 5 个参数的相同 NamedQuery 的情况)。