Summary
In this chapter we've looked at some of the key issues in data access in J2EE systems. We've discussed:
-
The distinction between business logic and persistence logic. While business logic should be handled by Java business objects, persistence logic can legitimately be performed in a range of J2EE components, or even in the database.
- The choice between object-driven and database-driven data modeling, and why database-driven modeling is often preferable.
- The challenges of working with relational databases.
- O/R mapping concepts.
- The use of Data Access Objects - ordinary Java interfaces - to provide an abstraction of data access for use by business objects. A DAO approach differs from an O/R mapping approach in that it is made up of verbs ("disable the accounts of all users in Chile") rather than nouns ("this is a User object; if I set a property the database will be transparently updated"). However, it does not preclude use of O/R mapping.
- Exchanging data in distributed apps. We discussed the Value Object J2EE pattern, which consolidates multiple data values in a single serializable object to minimize the number of expensive remote calls required. We considered the possible need for multiple value objects to meet the requirements of different use cases, and considered generic alternatives to typed value objects which may be appropriate when remote callers have a wide variety of data requirements.
- Strategies for generating primary keys.
- Where to implement data access in J2EE systems. We concluded that data access should be performed in EJBs or middle-tier business objects, and that entity beans are just one approach. Although middle-tier business objects may actually run in a web container, we saw that data access from web-specific components such as servlets and JSP pages is poor practice.
I have argued that portability is often unduly prioritized in data access. Portability of design matters greatly; trying to achieve portability of code is often harmful. An efficient, simple solution that requires a modest amount of persistence code to be reimplemented if the database changes creates more business value than an inefficient, less natural but 100% portable solution. One of the lessons of XP is that it's often a mistake to try to solve tomorrow's problems today, if this adds complexity in the first instance.
Comments
