问题
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?
回答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 :
- 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 Layeroperations with multiple UIs. You can also use business layer to work as a web service. - 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.
回答2:
If you're asking why it's a good idea to have a service layer that's used by the view, then the answer is that more often than not you want to access services from parts of the application that are different from a specific view.
For instance, suppose you had logic to validate an order, which at first was primarily used on some /order.xhtml page. It wouldn't hurt that page to have the Service and corresponding objects (say Order) right there in the view.
But then the requirement comes to do order validation from a batch job. If the code for that validation is tightly coupled to your view, this will be impossible or very hard and most likely be very awkward (I've seen people mocking a JSP PageContext since some business logic happened to require it).
There are quite some other situations where this creeps up, like e.g. an external API via JAX-RS, a totally different view (page for another user, or perhaps a mobile targeted UI), etc.
回答3:
Business logic layer should not be implemented on the service layer.
DAO/Service Layer -> Business Logic Layer -> UI Controllers
-rico
来源：https://stackoverflow.com/questions/12011330/java-ee-best-design-approach-business-logic-layer