Where do JavaFX FXML controllers belong in an ECB architictural design pattern?

Question

I am wondering where does the fxml controller belong in the Entity-Control-Boundary model?

When designing a JavaFX application with the help of Scene Builder, Scene Builder generates an fxml file which represents the GUI. In addition, a controller is needed to make user interaction possible. An example would be: LoginScreenUI.fxml & LoginScreenUIController.java.

What is known:

1. An entity object is an object that represents the system's data.
2. A boundary object is an object that interfaces with the system's users.
3. A control object is an object that implements the logic required to manage the various elements and their interactions. It serves as a mediator, i.e. the glue between boundary objects and entity objects.

All of the interpretations I found were based on a comparison to the MVC model, here are some:

• The Entity-Control-Boundary Pattern (ECB) is a variation of the Model-View-Controller Pattern.
  
  Mapping to MVC:
  We can map the inner hexagon filled with entities to the Model role in the Model-View-Controller Pattern. Controllers obviously map to Controllers, and boundaries, at least boundaries that interact with users, map to views.
  
  

• They are not similar. MVC is for user interaction. Business rules are not bound to users directly and even not I/O devices like the internet itself. The ECB pattern is used for separating business entities from the boundary (mvc framework, ORM's).

• 

I see myself agreeing with the explanation that ECB pattern is a kind of an analogous pattern to the MVC pattern when it comes to more Client-Server like architectures. As a consequence, some differences occur when implementing each one.

However, I am not entirely satisfied as I could not find any direct answer to my question and it is still open for personal interpretation rather than having a clear guideline.

To be more concrete, when the user types ID, Password & clicks the Login button. My controller handles that button click.
Two scenarios are possible: Assuming

1. Assuming my controller belongs to the Control category.
   I can right then and there check if the user is registered in my database by executing a query.
2. Assuming my controller belongs to the Boundary category.
   I have to find another "middleman" class to authenticate the credentials.

I can't move forward based on assumptions as a wrong one will significantly slow down future development and introduce many mistakes to be painfully corrected.

Any help would be much appreciated.

Thank you.

Answer 1

The Entity-Control-Boundary is an architectural pattern that has the purpose to make the link between use-cases and your code.

Architecture of ECB compared to MVC

ECB has some similarities with MVC. For instance, there is a straightforward relation between ECB-Entity and MVC-Model, and also between MVC-View and ECB-Boundary. But there is a big difference between ECB-Control and MVC-controler:

• In the original MVC the controller is part of the interface with the user, in the sense that the controller processes the user's input (whereas the view the output). According to this logic, any business logic should not be in the controller but in the model.
• In the ECB, the control implements a use case, which means it coordinates interactions with boundary and entity, but also ensures transactional business logic.

This means that if you want to map ECB-Control with MVC, you'd first have to reafactor your ECB-control, by spliting it into two parts:

• on one side the transactional logic and the interaction with the entity (MVC-M), which would be something like a transactional script if using Martin Fowler's terminology;
• on the other side the interaction with the boundary (MVC-C)

But what are your architectural objectives ?

The question is not so much what the architecture should be, and how to squeeze the square into the circle. The question is more what you want it to be. Do you want an MVC, MVVM, MVP or an ECB architecture ? And why ?

Your controller's goal is obviously to handle the user events ("My controller handles that button click"). So it belongs to the ECB-boundary. And if you want to adopt ECB, you should ensure a true separation of concern. So your controller should interact with another object that handles the application logic (here the connection) independently of the user interface. So the way to go would be your second choice.

Of course, it could be an overhead. Up to you to decide if it's worth the extra effort. Especially if your app is a front-end and the real application logic is anywey well encapsulated in a back-end.

But if you adopt such a structure, it has also advantages:

• you could one day decide to replace JFX with another technology: only the boundary would have to change (and this is in the spirit of the hexagonal architecture where the outer "adapter"-layer can be replaced without touching the inner core).
• you could test your business logic more easily, by having test cases that invoke directly the business logic wihtout going through the UI.
• you could one day replace your password-based login with SSO login , etc...

Hope this helps.