3

I'm working with JEE standard. I have the following layers: JPA (Eclipse Link), Data Access, Business Logic, and JSF (Primefaces). Primefaces uses MVC design pattern, so the the presentation layer contains the ManagedBeans (controllers).

When I create an object from an user request, must I contruct the object in the ManagedBean and pass it as the whole object to the logic, or should I pass the attributes of that object to the logic:

public void businessLogicMethod(String clientAttributeA, int clientAttributeB...)

or

public void businessLogicMethod(Client client)

I really can't make up my mind. Functionally, both options do the same... But are there any software quality advantages from one to the other? Is there any layer design reason to construct it in the controller or the model? Is there any other reason?

One of the advantages I see in the upper one is that the deployment diagram's services will have the parameters declared in the service interfaces, so there is much more information in the diagram.

  • The second approach could be a refactoring from the first approach. See parameter object. – Spotted Oct 7 '16 at 5:43
4

But are there any software quality advantages from one to the other?

Programming is complex and so we try to do things that make it more manageable and maintainable.

One tool we have for that is abstraction. If we can abstract the relevant details and hide the implementation of those details that gives us an advantage, because we can consider fewer rules and issues, and things just work.

Whenever you can take several concepts and bundle them together into one single abstraction, you're getting advantage.

So, taking string, int and packaging that as a class Client is an abstraction that helps clients (no pun intended), often us, to write better software with fewer concerns and opportunities for error.

One issue with two separate parameters is that someone could confuse clientA string with clientB int. Bundled together, that can't happen.

Another issue with the code you're showing is that the primitive data types don't offer as high value type checking, so someone could confuse some other string value with the string for clientA. Bundled together as in a new abstraction (a new class, its own type) that won't happen.

The concept of providing a quality abstraction that is less error prone is at the heart of writing maintainable code.

One of the advantages I see in the upper one is that the deployment diagram's services will have the parameters declared in the service interfaces, so there is much more information in the diagram.

This is actually contrary to what we want. We want to hide implementation details so that future changes perturb the smallest possible code surface.

Is there any layer design reason to construct it in the controller or the model?

You should construct your abstractions (here of Client) at the earliest practical moment, when you have the various attributes altogether. After that, an (single) abstraction is the best packaging of those attributes.

  • Are you suggesting to always abstract as much as possible? Should no method have more than one parameter? Or should all communication between layers happen through data transfer objects only? – Marco Borchert Oct 7 '16 at 6:54
  • I basically think the answers to Can too much abstraction be bad? apply here. – Marco Borchert Oct 7 '16 at 6:56
  • @MarcoBorchert, in this case, the multiple attributes (potentially more than just the two being shown as alluded to via the trailing ...) are pretty clearly logically part of the same abstraction. The method in the question, businessLogicMethod, is sufficiently generic so as to suggest there might be others like it, and in that case, we're talking about multiple places in the code that have to concern themselves, relatively unnecessarily, with the implementation details of clients. However, were these inferences from the wording and examples in the question false, YAGNI might apply. – Erik Eidt Oct 7 '16 at 15:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.