(实体 - 控制 - 边界模式) - >如何处理两个实体？

Question

前提

我最近阅读/观看了由Java Champion Adam Bien撰写的很多文章/视频,他主张使用古老但更新的 实体 - 控制 - 边界设计模式 JAVA EE> = 6.

利用CDI,EJB 3.1,JPA 2和其他JAVA EE 6功能,此模式应有助于创建更多面向业务的组件,更易于单元测试,并根据职责更高地分离关注点.

由于我使用了上面列出的所有功能,而且这种模式听起来非常有趣,我正在寻找它,看看ECB是否符合我的下一个项目要求.

到目前为止我得到了什么

在欧洲央行,每个逻辑实体分为三部分(如果我错了,请纠正我):

• 一个边界,一种强大的门面,只有类的访问之外.对于外部(如果我做对了),我们的意思是在应用程序之外,例如.远程客户端,在组件包之外,例如.我申请的另一部分;

• a(n可选)控制器,负责某种操作(例如,实体的验证);

• 一个实体,可以是一个纯粹的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次每个实体的搜索方法,然后执行插值,听起来像一个非常丑陋的方式,对性能产生巨大影响.我想我仍然需要一个中心点来执行这种事情.它应该是另一个组成部分,例如.Searches,在其边界中称为其他边界？这一点对我来说很模糊.

边问题

将ECB与基于动作的框架一起使用是否有意义？或者这种模式是否归结为基于组件的框架？

我正在使用Struts2,这是一个基于MVC动作的框架,我对JSF2(JAVA EE 6标准,在大多数Adam Bien的展示中使用)非常不熟悉,这是一个基于MVC组件的框架;

除了将架构视为"组件方式"的额外努力之外,还有什么东西阻止我在业务层使用ECB 吗？

由于Adam Bien的例子中的大多数边界都是REST服务(通常更多地取代Struts2动作而不是"链中的新装备"),这使我怀疑它可能完全适合Struts2生态系统.

说你的.请.

Answer 1

据我了解设计模式，你对“到目前为止你所得到的”是正确的。

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

现在以某种方式与你的附带问题（恕我直言）相关：ECB 对于小型项目来说是可以的，但对于更大的项目，你可能需要一个更多层次的结构：

• 一个仅处理来自用户的请求/输入的 Web 层（我不喜欢我的 EJB 知道HttpRequests 和HttpResponses）

• 具有 DAO 层的多层应用程序模型（对于 CRUD 操作不是必需的，但对于NamedQuery在多个 EJB 中使用 5 个参数的情况）。