This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hi all, So, the inevitable question has arisen -- more trips to the database, or more java objects to encapsulate the data. Suppose I have a class Employee, and a web application which provides an interface to manage Employees. What are your thoughts on:
initialize a List of Employee objects, populating each one with data from the database, and allow user to navigate through List, make modifications, etc.
initialize one Employee object (the Employee currently being viewed) and as the user selects another, retrieve data from database and update Employee object with data
The likely number of users at any given time is less than 100, and the number of Employees in the database is less than 500. What do you think? Thanks!
The number of users will not affect the memory footprint (unless the list is customized on a per-user basis), and with such a small number of objects, I do not see any issues with caching them in memory as long you understand the nuances of caching (like how do you fault items out of the cache when they are updated in the database and so on).
Well, I lost the argument for populating all the Objects, thus incurring only one roundtrip to the db. We decided to conserve memory, since each user will, in fact, have a customized list of Objects at their disposal, and this may lead to some memory overload (I guess, but I still don't think it is significant). Instead of populating a List of Objects, we populate one Object, and have a List of "scaled-down" Objects (with only a few key attributes for lookup in the db). When the user chooses to examine another Object, we look up the scaled-down Object attribute, send the query to the db, and retrieve the complete Object and dump it in the Session. In a nutshell, look at this pattern:
So, the Employee class represents the complete model of an Employee from the database. The EmployeeIndex represents only the info we need to lookup an Employee in the database (I'm not sure there should even be an inheritance relationship here). Essentially, a List of EmployeeIndex objects will be displayed on the jsp page and, in response to a click, the respective Employee object will be retrieved from the database.
So, it seems to me, the only savings we have is that the EmployeeIndex class does not have all the additional attributes of a full-blown Employee, and thus has a smaller footprint in memory. What do you guys think?