（实体 – 控制 – 边界模式） – >如何处理两个实体？

前提

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

利用CDI，EJB 3.1，JPA 2和其他JAVA EE 6function，这种模式应该有助于创建更多面向业务的组件 ，更容易进行unit testing，并根据职责更高地分离关注点。

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

到目前为止我得到了什么

在ECB中，每个逻辑实体分为三部分（如果我错了，请纠正我）：

  • 边界 ，一种强大的外墙，唯一可从外面进入的等级。 对于外部 （如果我做对了），我们的意思是在应用程序之外 ，例如。 远程客户端， 在组件包之外 ，例如。 我申请的另一部分;

  • a（n可选） 控制器 ，负责某种操作（例如，实体的validation）;

  • 一个实体 ，可以是一个纯粹的JPA实体，但也可以包含一些装饰/validation/（最小）业务逻辑。

例如，考虑有两个不同的实体（ Orange和Apple ），一个在它们FruitsManager做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生态系统。

说你的。 请。

据我所知，设计模式你是对的“你到目前为止”。

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

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

  • 一个只处理请求/用户输入的Web层（我不喜欢我的EJB知道HttpRequest和HttpResponse的想法）

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

Interesting Posts