Spring - Decoupling Vs Performance
java, spring, spring-mvc, standards
Solution
According to Spring's decoupling standards, this is how the calls should be made
This is false. There are no "decoupling standards" with Spring. Please find me a reference in the Spring documentation that tells you how you must structure your persistence layer code.
Typically, you would have one DAO for each "entity" that your application wants to operate on, but it would be foolish to take this pattern to the extreme of deconstructing a query that joins multiple tables together into three distinct queries.
If you need to have a `newMessage()` method that joins some tables together in a query, choose which DAO that makes the most sense in - probably the `MessageDAO` and write the query/method in the way that makes sense.
But there is no rule saying that you must have distinct queries for each entity and that one DAO class is not allowed to make queries that touch the tables of other entities. This is too extreme and has no benefit.
If one the other hand you are worried about the maintainability of having multiple data layer classes that are aware of all of your tables, then look into an ORM solution as parsifal mentioned to alleviate some of this work.
Problem
I have an application that has the following java files: Services: ``` AccountService.java UserService.java MessageService.java ``` DAOs: ``` AccountDAO.java UserDAO.java MessageDAO.java ``` Tables: ``` ACCOUNTS USERS MESSAGES ``` In `MessageService.java`, I have a function `newMessage()` that has to query data from all the 3 tables. (1) According to Spring's decoupling standards, this is how the calls should be made: ``` AccountDAO.java -- ACCOUNTS / MessageService.java -- MessageDAO.java -- MESSAGES \ UserDAO.java -- USERS ``` But the problem is, this approach makes 3 DB calls. (2) For better Performance, I would do: ``` MessageService.java -- MessageDAO.java -- Join ACCOUNTS, MESSAGES and USERS ``` But this way, it's tightly coupled and if there's a change in USERS table, I'll have to change MessageDAO.java (and all other DAOs that I have, that use the USERS table) too. That is really bad, since (in the non-hypothetical) we have a LOT of DAOs Which approach is considered a better practice? Or is there another approach that I'm missing?