Yes, the DAO gives you data from the persistence layer. I’m not clear on what is your point.

If the logic behind OutstationEmployees becomes more complex, the code will have to change anyway. It doesn’t matter a lot if the code that changes is in the native language of the app or the SQL query it sends to the database. (I also don’t consider adding a WHERE clause to be “highly optimized SQL.”)

Cacheing can certainly help in some situations. With regard to collections of things, I would reserve caching for things that are needed frequently relative to the rate of change. Otherwise you’ll be invalidating your cache on a frequent basis.

If you can hold the entire contents of your database in memory, then maybe a relational database is the wrong sort of persistence for your application. I think for most business applications, at least the ones I’ve developed, holding in memory the data on all employees would be a bigger limitation than writing a SQL query.

In what ways does the “data tier not scale well?” Certainly it can handle larger amounts of data in mass storage than local memory. What issues do you have in mind?

>> This can create performance and scalability issues in a hurry. It makes me wonder why people jump to this sort of implementation.

public List getOutstationEmployees() {
List emps = employeeDao.getEmployeesByAddress(corporateOffice);
List allEmps = employeeDao.getAllEmployees();
return CollectionUtils.minus(allEmps, emps);
}

Of course, I could use 1 highly optimized SQL query to find OutstationEmployees. What happen if the logic behind OutstandEmployees become more complex?

IMHO, data tier doesn’t scale well. It might be better if I could move some logic to application server. By applying caching on business logic method using AOP, then I don’t have to go data tier everytime when I need list of AllEmployees, OutstationEmployees,…