|
|
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 app's core workflow. It's independent of the app's user interface, and where persistent data is stored. In contrast to business logic, persistence logic concerns the app's access to and manipulation of persistent data. Persistence logic normally has the following characteristics:
It doesn't require the app 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.
| 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 app. Important choices that we'll consider in this chapter and the next two chapters include:
JDBC and SQL (for accessing relational databases)
|
|