Once upon a time, I wrote a collection database access components in Java that was basically Collection-to-Relational Mapping tool (you can download the code in the form of a number of JavaBeans). It would move the data from a ResultSet to a Map or List, and these sorts of objects could then be easily viewed and manipulated by front-end template engines (i.e. JSP, and especially FreeMarker).

The downside of such an approach is the difficulty in implementing the business logic.

Where you put the business rules (or “application logic”) often depends on the framework you use. Clearly, this shouldn’t sit in the “View” or the “Model” sections (if you use the MVC paradigm), but a good framework should break the “Controller” into two sections, one that controls the application, and one that isolates the changing business rules.

Business rules often need to manipulate, restrict, or add to the data coming from the model, and how should the data be organized to best support this? For simple database-oriented applications that don’t have much in the way of business logic, placing the model’s data in collections is quite easy and effective.

However, for larger, more complex applications, it is better to store these in dedicated class objects. If the resulting objects can integrate the business rules, then your application’s code becomes clearly organized.

There are a number of tools that do this object-to-relational mapping, and the best would allow for the integration of business rules— actually I should say, the separation of the data and the business rules with its final re-combination in the form of the object.

Yes, clearly this would be the best reason for Aspect-Oriented Programming (AOP) where the business logic could be written in a high-level (even scriptable language), and then have its source be combined with the source code of the database objects.

Until AOP pervades all of our development, the Java industry seems to be settling on using the Spring Framework in combination with standard ORM tools, like Hibernate.