I have little problem with finding the border between DAO and business layers in my web application based on Struts. Let's assume that I want to display web page with all users of my app. In UserDAO class I have method findAll() which returns all the users. The problem is that I don't know if it is ok to have direct refference from Struts actions to DAO layer objects. Maybe it should be done via business layer? For me it is not very correct to have reference in Struts Action directly to DAO layer (because I would have direct link from presentation layer to persistence layer), but from the other side it is also weird for business layer to act as some kind of facade, which will just redirect all find requests to DAO layer and I don't know if simply getting the data from database just to display it at web page (without any modification) is a kind of business case.
I would like to know how it is done by experts;) because it is my first web project
I would recommend creating a separate business class called User with methods like create, authenticate, findAll etc. and a DAO class called UserDAO for DB operations. Your action class should use the business class method which internally uses the DAO class to get the data from DB.
By this approach you will have separated the concerns of persistence, presentation and business processing. I can understand why you are not able to decide about introducing an extra business layer when all that it is doing is just forwarding the call to the DAO. What you need to consider is the possible evolution of this application. Somewhere down the line, your customers will demand more features which will force you to add more use cases related to User class which might not be simple DB CRUD operations. Having a business layer in-between your presentation and persistence is a good architectural decision to handle such modifiability scenarios.
Your doubt actually highlights the difference between architecting a solution and designing a solution. Architecture tries to handle all sorts of quality attributes like modifiability, performance, scalability, testability etc in your solution whereas design just focuses on realizing the use cases in the cleanest way ( coupling , cohesion, variation points etc.. )
Yes, as Rahul said it is there to decouple your presentation tier and data tier and it enhances your applicaiton's flexibility. It is an architectural decision to introduce a business layer or not. Though you dont see a big advantage for this use case you will definitely feel the advantage of business layer for your most other use cases. So you should not deviate from your architecture for every use case that will seriously affect your application's maintainability.
Even for the use case you mentioned, your business layer should translate your data base exceptions to meaningful business exceptions.
Subramanian, Kumar [kumar at eminenttech dot com]
Eminent Technology Solutions (ETS) [www.eminenttech.com]
Software / Portals / Alfresco / Outsourcing / Proteomics
Thanks Guys for your replies, I think you are right. Your arguments are quite logic for me, I was just a little bit confused with the vision of case where these business method just redirect request to DAO. But I agree that it is the way better solution from architectural point of view. And the translating the data base exception is another reason to do it that way.
I have also wondered what do you guys think about using Transfer Object pattern. I know that it generally depends on architecture and level of modularity. But let's assume that right now I'm working only at web application. What is the most common practice or the recommended one? Of course I would like not to limit possible functionality of my application, because in the future another parts of system may be built on current solution, i.e. some RCP or WebServices support.