(Entity-Control-Boundary pattern) -> How to deal with two entities?

Question

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 remote 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 performance. I guess I still need a central point somewhere to perform this kind of thing. Should it be another component, called e.g. 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 an 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 an 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.

Answer 1

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).