Business Logic and Persistence Logic

The second and third of the above goals imply a distinction between business logic and data access, which it is important to clarify.

Business logic is concerned with the application's core workflow. It's independent of the application's user interface, and where persistent data is stored.

In contrast to business logic, persistence logic concerns the application's access to and manipulation of persistent data. Persistence logic normally has the following characteristics:

• It doesn't require the application of business rules. As in the above example, persistence logic handles the details of a task that has already been decided on. If deleting a user involved cascading deletes only under certain circumstances, a business logic component would be used to make the decision and request operations as necessary.

• It is unlikely to change on updates to business rules.

• It doesn't need to handle security issues.

• It may involve preserving data integrity.

• It requires knowledge of the target persistence store to implement (although not to define) operations.

Important 

Persistence logic is not only distinct from business logic; it's a good idea to remove it entirely from business logic components. The business rules captured in Java business objects will be much more clearly expressed and easier to maintain if the nuts and bolts of persistence management are moved into helper classes.

While business logic should be handled by Java objects – often, but not necessarily, session EJBs – there are many choices for implementing persistence logic in a J2EE application. Important choices that we'll consider in this chapter and the next two chapters include:

• JDBC and SQL (for accessing relational databases)

• Entity beans

• Java Data Objects (JDO)

• Third-party persistence frameworks such as TopLink

• Stored procedures, which can sometimes be used appropriately to move persistence logic inside a database