13

前提

我最近阅读/观看了 Java Champion Adam Bien 的很多文章/视频，他在其中提倡使用古老但更新的 实体 - 控制 - 边界设计模式JAVA EE >= 6。

利用 CDI、EJB 3.1、JPA 2 和其他 JAVA EE 6 特性，这种模式应该有助于创建更多面向业务的组件，更容易进行单元测试，并基于职责实现更高的关注点分离。

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


到目前为止我所拥有的

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

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

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

  • 一个Entity，可以是纯 JPA Entity，但也可以在里面包含一些装饰/验证/（最小）业务逻辑。

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

直到昨天，它本来就像（旧方式）：

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 次，然后执行插值，听起来是一种非常丑陋的方式，对性能影响巨大。我想我仍然需要一个中心点来执行这种事情。是否应该是另一个组件，称为 eg Searches，在其边界中调用其他边界？这一点对我来说是模糊的 ATM。


附带问题

将欧洲央行与基于行动的框架一起使用是否有意义？还是这种模式归入基于组件的框架？

我正在使用 Struts2，这是一个基于 MVC 动作的框架，我对 JSF2（JAVA EE 6 标准，并在大多数 Adam Bien 的展示中使用）非常陌生，它是一个基于 MVC 组件的框架；

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

由于 Adam Bien 示例中的大部分边界是 REST 服务（通常更多的是替代 Struts2 Actions 而不是“链中的新设备”），这让我怀疑它是否完全适合 Struts2 生态系统。

说你的。请。

4

1 回答 1

4

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

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

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

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

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

于 2014-11-03T10:28:34.337 回答