How to design layer architecture for web application?

Question

I have design issue when implement 1 simple web application. I use struts2 web controller, spring's IOC and Hibernate as persist layer.

Because this web application is very simple at begging. So I only have 2 layers: 1 DAO layer which used to access database. Almost every table have related DAO. 2 Action layer. User struts2. I am satisfy with this architecture because can quickly implement my web application. As project become bigger, I found the action layer become big and complex, and very hard to re-use. I try to create service layer, to solve complex business logic is good, but my application still have a lot of simply logic. Eg: Load 1 object, save 1 object, and get collection by some condition and display it to webpage. If give each simple DB access method have corresponding service method. Still cost a lot of effort. How can solve this issue? And I think, if service layer existing, direct call DAO layer still not good design for my application. Is any good solution for this kind of small web application?

Answer 1

When planing the different layers in a web application it is good practice to explicitly protect attributes and associations in your model from being manipulated without providing an identity context.

This is something that should neither be done in the DAO layer nor in the Controller. You should wrap your DAO layer in a service layer and have the controller only talk to the services not the DAO directly.

Protecting your model against unwanted manipulation means that you for instance adapt the amount of information passed in a data structure between Controller and Service to the actual operation that you want to perform.

For instance: adding or removing an element from a collection is an explicit operation in the service, it does not happen implicitly by manipulating a collection as a member of a DAO object and passing that DAO back into the service.

Instead your service may look like this:

+ getAllCompanies(): CompanyType[*]
+ getAllEmployeesOfCompany(c: CompanyType) : EmployeeType[*]
+ addEmployeeToCompany(e: EmployeeType, c: CompanyType)
+ removeEmployeeFromCompany(e: EmployeeType, c: CompanyType)

The additional benefit of such an architecture is that the service layer serves as boundary for your transactions. Using the methods of your controller as boundary for your transactions is in fact a very bad habbit. You could even call it an anti-pattern. Why? Because for instance it would mean that when your client hangs up it would roll back your transaction. That is clearly unwanted in 99% of the cases.

Answer 2

As @mwhs commented, Apache Isis provides plenty of guidance on layering your app. To figure out whether it fits your requirements, you could run through this tutorial I presented at a recent conference.