Question

The project I am working with uses JSF + Spring + Hibernate.

This is a design question that I have often been confused about.

I currently inherited a project that contains a dao -> service -> view -> controller “layered” approach.

The “Controller” layer / tier? currently has all logic and objects that interact with the front end. I have been told that it is good practice to separate this into two layers/tiers, where the “Controller” layer/tier only contains methods/objects that interact with the front end and a second layer (bm?) that contains all business logic used by the controller.

1st.) What would the purpose be of dividing up the controller in such a way?

2nd.) Is there anything wrong with leaving it the way it currently is?

Answer 1

1st.) What would the purpose be of dividing up the controller in such a way?

You must handle the business logic in Service Layer. Benefits of separating the business entities from Controller/UI Layer :

1. You can reuse the business entities with another client sections. Example : if you are developing a web based application as UI, later you also developed a Desktop UI. In this case you can reuse your Business Layer operations with multiple UIs. You can also use business layer to work as a web service.
2. Decoupled business operations are easier to manage. If someone from development team has no idea how UI code works and only wants to correct some business logic, he can does.

2nd.) Is there anything wrong with leaving it the way it currently is?

If you are new to Layered Architecture it will take some time to understand and implement the desired layers. It depends on time frame and application requirements. If you are planning to use the above points in your application go with layered architecture otherwise go with current implementation.