A typical J2EE application using an O/R Mapping tool is faced with the task of fetching the required data using a minimal set of SQL queries, which is not always an easy task. By default the O/R Mapping tool loads data on demand unless otherwise instructed to. This behavior known as Lazy Loading ensures that dependents are only loaded as they are specifically requested and hence makes it possible to avoid unnecessary creation of objects. Because of the lazy loading, DB performance reduces when a large number of Select queries are executed, as all the required data for a business case are not fetched at once. This might prove a bottleneck for an application which needs to support a large number of requests.
In this article Manjunath R. Naganna introduces a strategy for overriding the default fetching pattern in the Repository/DAO class with a different fetching pattern based on the specific use case as defined with Aspect Oriented Programming. Aspect helps in deciding which fetching strategy needs to be used in a particular business use case. In this case, fetching strategy decision management is kept outside the lower level service or repository layer.
Read: Fetching strategy implementation in a J2EE application using AOP
The logic of deciding which query needs to be executed is a crosscutting concern that is retained in an Aspect. Aspect decides which fetching strategy needs to be injected in the repository before the service layer executes the API on the repository based on business use case. By this we can use the same service and repository layer APIs to satisfy different business use case requirements.