\ / \/
Business Logic --->Business Object Model
\ / |
#1 The Business Object Model
The BO serves as the foundation for the rest of the application. It is the object-oriented representation of the problem domain, and therefore the classes that make up the businss object model are sometimes called domain classes. All other layers use the business object model to represent data and perform certain business logic functions.
Application designers usually start with the design of the business object model before anything else. Even if at a very high level, the classes are identified by deriving them from the nouns in the system. For example, in a bookstore application, the business object model might include a class called Genre(Category) with instances like Science Fiction, Mystery, and Children's. It might also have a class called Book with instances such a The Long Walk, The Firm and Curious George. As the application grows more advanced, clases represent more abstract concepts, like InvoiceLineItem.
Business object model classes may contain some logic as well, but they should never contain any code that accesses any other layer. Other layers use the business object model - it's never the other way around.
A persistence layer like iBATIS will generally use the business object model for the representing data that is stored in the database. The domain classes of the business object model will become the parameters and return values of the persistence methods. It is for this reason that these classes are sometimes referred to as data transfer objects(DTOs). Although data transfer is not their only purpose, it is a fair name from the perspective of a persistence framework.
#2 The presentation layer
Although the presentation layer does not generally talk directly to the persistence framework, certain decisions about the user interface will impact the requirements for your persistence layer. For example, consider a web application that deals with a large list of 5,000 items. We wouldn't want to show all 5,000 at the same time, nor would it be ideal to load 5,000 items from the database all at once if we weren't going to use them right away. A better approach would be to load and display 10 items at a time. Therefore, our persistence layer should allow for some flexibility in the amount of data returned and possibly even offer us the ability to select and retrieve the exact 10 items that we want. iBATIS can help achieve these goals using features that allow querying for specific ranges of data.
# 3 The business logic layer
The business logic layer of the application describes the coarse-grained services that the application provides. For this reason they are sometimes called service classes.
At a high level, anyone should be able to look at the classes and methods in the business logic layer and understand what the system does. For example, in a banking application, the business logic layer might have a class called TellerService, which methods like openAccount(), deposit(), withdrawal() , and getBalance(). These are very large functions that involve complex interactions with databases and possibly other systems. They are much heavy to place into a domain class, as the code would quickly become in-cohesive coupled, and generally unmanageable. The solution is to separate the coarse-grained business functions from their related business object model. This separation of object model classes from logic classes is sometimes called noun-verb separation.
Object-oriented purists might claim that this design is less object oriented than having such methods directly on the related domain class. Regardless of what is more of less object oriented, it is a better design choice to separate these concerns. The primary reason is that business functions are often very complex. They usually involve more than one class and deal with a number of infrastructural components, including databases, message queues, and other systems. Furthermore, there are often a number of domain classes involved in a business function, which would make it hard to decide which class the method should belong to. It is for these reasons that coarse-grained business functions are best implemented as separate methods on a class that is part of the business logic layer.
Don't be afraid to put finer-grained business logic directly on related domain classes. The coarse-grained service methods in the business logic layer are free to call the finer-grained pure logic methods built into domain classes.
In the layered architecture, the business logic layer is theconsumer of the persistence layer services. It makes calls to the persistence layer to fetch and change data. The business logic layer also makes an excellent place to demarcate transactions, because it defines the coare-grained business functions that can be consumed by a number of different user interfaces or possibly other interfaces, such as a web service.
#4 The persistence layer
The persistence layer is where iBATIS fits and is therefore the focus on this learning series. The persistence layer should hide all details of how the data is being stored and how it is retrieved. Such details should never be exposed to the other layers of the applications.
To better understand these concerns and how they're managed, it helps to separate the persistence layer into three basic parts: the abstraction layer, the persistence framework, and the driver or interface.
#4.1 The role of the abstraction layer is to provide a consistent and meaningful interface to the persistence layer. It is a set of classes and methods that act as a facade to the persistence implementation details. With a proper abstraction layer in place, the entire persistence approach - including both the persistence API and the storage infrastructure - should be able to change without modifications to the abstraction layer or any of the layers that depend on it. These are patterns that can help with the implementation of a proper abstraction layer, the most popular of which is the Data Access Objects(DAOs) pattern.
#4.2 The persistence framework
it is responsible for interfacing with the drivers. The persistence framework will provide methods for storing, retrieving ,updating , searching , and managing data. Unlike the abstraction layer, a persistence framework is generally specific to one class of storage infrastructure.
#4.3 The driver of Interface
The storage infrastructure can be as simple as a comma-delimited flat file or as complex as a multimillion-dollar enterprise database server. In either case, a software driver is used to communicate with the storage infrastructure at a low level. It is the job of the persistence framework to communicate with the driver so that these differences are minimized and simplified.
#5 The relational database
iBATIS exists entirely to make accessing relational databases easier. Databases are complex beasts that can involve a lot of work to use them properly. The database is responsible for managing data and changes to that data.