How should a DAO layer be implemented? One table DAO or multiple table DAO?

0
votes

I am implementing a module as per layered architecture. It will have a presentation layer, service layer, a business layer and a DAO layer. As per layered architecture guidelines, the communication flow should be top to bottom. Similarly, the dependency should also be top to bottom i.e. presentation layer - uses -> service layer - uses -> business layer - uses -> DAO layer. i.e. business layer should not depend on service layer and likewise.

Question 1:

What should be the inputs to each layer? Since, the service layer is called from presentation layer, should the service layer accept UI bean as the input? or Service Bean as the input ? Same for business and DAO layers.

Question 2:

Should the DAO layer be per table or can it handle multiple tables (all owned by a single module) ? The data of my module gets stored in multiple tables. Since all these tables are owned by a single module, i think it makes sense to have a single DAO layer which abstracts the multi-table storage of the data from upper layers. Also, if different implementations of a DAO layer needs to be plugged (database storage, SVN storage etc), it makes sense to have a single implementation plugged (which handles all data). Also, multiple table DAO would be performance efficient in terms of fetching data ( a single join query would suffice )

Question 3:

If multiple table DAO design is considered, then the input to the DAO layer would be business bean. It is the responsibility of the DAO layer to convert the business bean to multiple DB beans each representing a table and handling the persistence. But this would not be compliant with the layered architecture where it says that layers should be isolated and any layer should not depend on its upper layer. In this case, the input to DAO layer is business bean (not DB bean) and the conversion from business bean to DB beans and vice-versa is the responsibility of the DAO layer which means it knows how to convert a business bean to DB bean and vice-versa.

Can someone please clarify on the above? What should be the proper way to implement such a module? Is the current implementation as per guidelines? A proper explanation would help a lot. Thanks!

The current implementation I have is

  • Presentation layer: converts UI bean to service bean and passes it to Service layer.

  • Service layer: converts service bean to business bean and passes it to Business layer. Also orchestrates calls between various dependent services. Handles transaction boundary. Returns service bean to presentation layer.

  • Business layer: passes business bean to DAO layer. Returns service bean to service layer

  • DAO layer: Converts business bean to DB beans and vice-versa. Returns business bean to business layer.

1
architecturedaodependency-managementdesign-principleslayered

1 Answers

1
votes

I will use the example of a social network website throughout this answer.

  1. Your UI should depend on your service, but only unidirectionally. Imagine the case when you have some posts on the UI and you intend to implement the feature of "Like". Intuitively, when a user clicks on the Like button for a post, a record in the corresponding table should be created and later shown on the UI. So, you need a Like feature implemented, which, on the UI means that you have a POST request handler which calls the corresponding method in the service layer, passing the user's ID and the post's ID. The service layer should be totally agnostic to the UI and should only handle the session validation and call the corresponding method in the business layer. Your business layer should, on its turn handle the logic of your action and ensure that your methods in the DAO layer are being called, so a Like record is created in the database and possibly some other things might happen that you might need. When all the DAO methods to be called are successfully executed (if not, then the error will have to be properly handled), the Business layer should respond to the service layer, which, in turn should send the emails to the users to be notified and respond to the UI.

  2. Beware the dragon called "premature optimization". You should have a single DAO layer, because it will largely simplify your life. If later you have some performance issues, then you will have to solve them. However, if you are going to have performance issues, it is highly probable that it will be caused by something else. DAO layer means that you have a layer where your DAO is being represented.

  3. See point 2.