The general hierarchical structure of the project using the following outlook is struts2:
Layer is very clear, but there is real development problems
For example, if we replace the struts2 this layer, switch to the phone side, so you can reuse something behind it? Business logic can be reused it?
Now the service layer on only responsible for the dao to add a transaction simple package, or combination of point dao layer of logic to a call, a large number of service injected into the struts layer, struts2 layer under the project to achieve the function assembled out of business operations, then re-package the presentation layer stuff, and then to call the show floor, the control of affairs at this time due to the action on which combination of these service and lost a role.
action-layer theory is that things get front layer, and then assembled the parameters we want, then call the relevant service level of service can be, but now services a large area of what appears in the action inside.
For this reason, when estimates are developed to understand the problem, although there are hierarchical, layered or not very good but the actual realization of the concept of layering has become a must do, without understanding the responsibilities of each. That is, development time, struts2 use must be clear, I just call into the service, through service to get the foreground to the show, and by calling the service, so that service area to deal with some things.
Summarize the problems posed:
1.action layer of code bloat, change is not easy to see that many classes have reached the 600 lines of code
2 things that control is not clear, the Department has been to bring the theoretical aspects of the problem:
1. Stratification is not clear, each of the duties of expression is not good
2.service too light, just a simple package dao