（实体控制边界模式） - >如何处理两个实体？ [英] (Entity-Control-Boundary pattern) -> How to deal with two entities?

问题描述

前提

我最近读过/观看了Java Champion Adam Bien的许多文章/视频，他主张 实体 - 控制 - 边界设计模式 JAVA EE> = 6。

利用CDI，EJB 3.1，JPA 2和其他JAVA EE 6功能，这种模式应该有助于创建更加面向企业的组件，更容易进行单元测试，并根据职责分离更多的关注点。

由于我使用上面列出的所有功能，这种模式听起来很有趣，我正在侦察它，看看ECB是否符合我的下一个项目要求。

我到目前为止

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

• a 边界，这是一种功能强大的外墙，唯一可以从 访问的类。而对于 （如果我正确的话），我们的意思是应用程序之外，例如。远程客户端，组件包之外的AND ，例如。我的应用程序的另一部分;




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




• 一个实体，这可以是纯JPA实体，但也可以包含一些装饰/验证/（最小）业务。

例如，考虑有两个不同的实体橙色和 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 * / 
  

同时使用ECB（ NEW WAY ）：

  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.apple s.entity.Apple / * ENTITY * / 
  

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

  Oranges.findOrangesByPrice（min，max）; 
  

主要问题

如何处理跨组件研究，例如 findFruitsByPrice（ min，max） ？

我应该同时调用 findOrangesByPrice 和 findApplesByPrice 并对结果求和？从哪个类，包装在哪里？
如果我有一个包含许多标准的搜索页面，那么必须跨越50个实体？运行50次每个实体的搜索方法，然后执行插值，听起来像一个非常丑陋的方式对性能有很大的影响。我想我仍然需要一个中心点来执行这种事情。应该是另一个组件，叫做eg。 搜索，在边界中调用其他边界？这一点对我来说是不明智的。

侧面问题

使用ECB与基于动作的框架是否有意义？或者是将这种模式降级到基于组件的框架？

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

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

由于Adam Bien的示例中大部分边界是REST服务（通常更多的是替换Struts2 Actions而不是新的链接中的齿轮），这使我怀疑它可能完全适合Struts2生态系统。

说出你的意见。

解决方案

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

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

现在以某种方式与您的侧面问题相关（ IMHO ）：
ECB对于小型项目来说可以，但是对于更大的项目，您可能需要一个更为分层的结构：

• 只是处理来自用户的请求/输入（我不喜欢我的EJB知道关于 HttpRequest s和 HttpResponse s）




• 一个多层应用程序模型，具有DAO层（不是CRUD操作的强制性，但是对于使用相同的code> NamedQuery 在多个EJB中有5个参数）。

Premise

I've recently read/watched a lot of articles/videos by Java Champion Adam Bien, where he advocates the usage of the ancient but renewed Entity - Control - Boundary Design Pattern JAVA EE >= 6.

Leveraging on CDI, EJB 3.1, JPA 2 and other JAVA EE 6 features, this pattern should help creating more business-oriented components, easier to unit-test, and with a higher separation of concerns based on the responsibilities.

Since I'm using all of the features listed above, and this pattern sounds very interesting, I'm scouting it to see if ECB can fit my next project requirements.

What I've got so far

In ECB each logical entity is split in three pieces (please correct me if I'm wrong):

• a Boundary, a sort of powerful Façade, the only Class accessible from outside. And for outside (if I got it right), we mean both outside the application, eg. a remot client, AND outside of the component package, eg. another part of my application;

• a(n optional) Controller, responsible for some kind of operations (for example, the validation of the Entity);

• an Entity, that can be a pure JPA Entity, but can also contain some decoration / validation / (minimal) business logic inside.

For example, consider having two different entities (Orange and Apple), a class to do CRUD on them (FruitsManager) and a class to perform some controls over them (FruitsQualityChecker).

Until yesterday, It would have been something like (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  */

while with ECB I would have (NEW WAY):

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  */

Then I can CRUD and research each entity singularly, eg. with

Oranges.findOrangesByPrice(min, max);

Main Question

How should I handle a cross-component research, like for example findFruitsByPrice(min,max) ?

Should I call both findOrangesByPrice and findApplesByPrice and summing the results ? From which Class, packaged where ? And what if I have a search page with many criteria, that must cross 50 entities ? Running 50 times the search method of each entity, and then perform the interpolation, sounds like a very ugly way with a huge impact on the performance. I guess I still need a central point somewhere to perform this kind of things. Should it be another component, called eg. Searches, that in its Boundary calls the other boundaries ? This point is obscure to me ATM.

Side Question

Does it make sense to use ECB with an action-based framework ? Or is this pattern relegated to component-based frameworks ?

I'm using Struts2, that is a MVC action-based framework, and I'm quite unfamiliar with JSF2 (JAVA EE 6 standard, and used in most of Adam Bien's showcases) that is a MVC component-based framework;

Apart from the additional effort of thinking the architecture "the component way", is there something preventing me to use ECB on the business layer ?

Since the majority of the boundaries in Adam Bien's examples are REST services (generally more a replacement of Struts2 Actions than a "new gear in the chain"), this makes me doubt it could be completely suitable for a Struts2 ecosystem.

Say yours. Please.

解决方案

As far as I understand the Design Pattern you are right with what "you got so far".

To your main question: as in other design pattern you can simply introduce another SuperComponent that is used in some endpoints (or a single, so that it does not get extremely big). That SuperComponent will do the things the correct way: you will use some existing Components if needed so that the performance and code quality do not suffer. What I mean here: you will probably write logic that relates to that specific endpoint that does not care whether it returns Oranges AND Apples, making a single query to DB (if your domain model is able to do that). Using the other components to fetch those fruits and make a union of them is a bad design, no matter what Design Patterns you use (image you will get Avocados later and then you will have to write code / correct bugs in order to get support for the new fruits).

Now somehow related to your side question (IMHO): ECB is OK for small projects, but for bigger projects, you will probably want a more-layered Structure:

• a Web layer that just process the requests / the input from the user (I do not like the idea that my EJBs know about HttpRequests and HttpResponses)

• a multi-layered application model, with a DAO layer (not mandatory for CRUD operations, but for the case you use the same NamedQuery with 5 parameters in multiple EJBs).

这篇关于（实体控制边界模式） - >如何处理两个实体？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！