The CaveatEmptor application

The CaveatEmptor online auction application demonstrates ORM techniques and Hibernate functionality; you can download the source code for the application from http://caveatemptor.hibernate.org. We won’t pay much attention to the user interface in this book (it could be web based or a rich client); we’ll concen-trate instead on the data access code. However, when a design decision about data

access code that has consequences for the user interface has to be made, we’ll nat-urally consider both.

In order to understand the design issues involved in ORM, let’s pretend the CaveatEmptor application doesn’t yet exist, and that you’re building it from scratch. Our first task would be analysis.

3.1.1 Analyzing the business domain

A software development effort begins with analysis of the problem domain (assuming that no legacy code or legacy database already exists).

At this stage, you, with the help of problem domain experts, identify the main entities that are relevant to the software system. Entities are usually notions understood by users of the system: payment, customer, order, item, bid, and so forth. Some entities may be abstractions of less concrete things the user thinks about, such as a pricing algorithm, but even these would usually be understand-able to the user. All these entities are found in the conceptual view of the busi-ness, which we sometimes call a business model. Developers and architects of object-oriented software analyze the business model and create an object-ori-ented model, still at the conceptual level (no Java code). This model may be as simple as a mental image existing only in the mind of the developer, or it may be as elaborate as a UML class diagram created by a computer-aided software engi-neering (CASE) tool like ArgoUML or TogetherJ. A simple model expressed in UML is shown in figure 3.1.

This model contains entities that you’re bound to find in any typical auction system: category, item, and user. The entities and their relationships (and perhaps their attributes) are all represented by this model of the problem domain. We call this kind of object-oriented model of entities from the problem domain, encom-passing only those entities that are of interest to the user, a domain model. It’s an abstract view of the real world.

The motivating goal behind the analysis and design of a domain model is to capture the essence of the business information for the application’s purpose.

Developers and architects may, instead of an object-oriented model, also start the application design with a data model (possibly expressed with an Entity-Relation-ship diagram). We usually say that, with regard to persistence, there is little

Figure 3.1 A class diagram of a typical online auction model

difference between the two; they’re merely different starting points. In the end, we’re most interested in the structure and relationships of the business entities, the rules that have to be applied to guarantee the integrity of data (for example, the multiplicity of relationships), and the logic used to manipulate the data.

In object modeling, there is a focus on polymorphic business logic. For our purpose and top-down development approach, it’s helpful if we can implement our logical model in polymorphic Java; hence the first draft as an object-oriented model. We then derive the logical relational data model (usually without addi-tional diagrams) and implement the actual physical database schema.

Let’s see the outcome of our analysis of the problem domain of the Caveat-Emptor application.

3.1.2 The CaveatEmptor domain model

The CaveatEmptor site auctions many different kinds of items, from electronic equipment to airline tickets. Auctions proceed according to the English auction strategy: Users continue to place bids on an item until the bid period for that item expires, and the highest bidder wins.

In any store, goods are categorized by type and grouped with similar goods into sections and onto shelves. The auction catalog requires some kind of hierar-chy of item categories so that a buyer can browse these categories or arbitrarily search by category and item attributes. Lists of items appear in the category browser and search result screens. Selecting an item from a list takes the buyer to an item-detail view.

An auction consists of a sequence of bids, and one is the winning bid. User details include name, login, address, email address, and billing information.

A web of trust is an essential feature of an online auction site. The web of trust allows users to build a reputation for trustworthiness (or untrustworthiness). Buy-ers can create comments about sellBuy-ers (and vice vBuy-ersa), and the comments are vis-ible to all other users.

A high-level overview of our domain model is shown in figure 3.2. Let’s briefly discuss some interesting features of this model.

Each item can be auctioned only once, so you don’t need to make ^Item dis-tinct from any auction entities. Instead, you have a single auction item entity named ^Item. Thus, ^Bid is associated directly with ^Item. ^Users can write ^Comments about other users only in the context of an auction; hence the association between ^Item and ^Comment. The ^Address information of a ^User is modeled as a separate class, even though the User may have only one Address; they may alter-natively have three, for home, billing, and shipping. You do allow the user to have

many BillingDetails. The various billing strategies are represented as subclasses of an abstract class (allowing future extension).

A Category may be nested inside another Category. This is expressed by a recursive association, from the ^Category entity to itself. Note that a single Cate-gory may have multiple child categories but at most one parent. Each ^Item belongs to at least one ^Category.

The entities in a domain model should encapsulate state and behavior. For example, the ^User entity should define the name and address of a customer and the logic required to calculate the shipping costs for items (to this particular cus-tomer). The domain model is a rich object model, with complex associations, interactions, and inheritance relationships. An interesting and detailed discussion of object-oriented techniques for working with domain models can be found in Patterns of Enterprise Application Architecture (Fowler, 2003) or in Domain-Driven Design (Evans, 2003).

name : String name : String description : String

Figure 3.2 Persistent classes of the CaveatEmptor domain model and their relationships

In this book, we won’t have much to say about business rules or about the behavior of our domain model. This isn’t because we consider it unimportant;

rather, this concern is mostly orthogonal to the problem of persistence. It’s the state of our entities that is persistent, so we concentrate our discussion on how to best represent state in our domain model, not on how to represent behavior. For example, in this book, we aren’t interested in how tax for sold items is calculated or how the system may approve a new user account. We’re more interested in how the relationship between users and the items they sell is represented and made persistent. We’ll revisit this issue in later chapters, whenever we have a closer look at layered application design and the separation of logic and data access.

NOTE ORM without a domain model—We stress that object persistence with full ORM is most suitable for applications based on a rich domain model. If your application doesn’t implement complex business rules or complex interactions between entities (or if you have few entities), you may not need a domain model. Many simple and some not-so-simple problems are perfectly suited to table-oriented solutions, where the application is designed around the database data model instead of around an object-oriented domain model, often with logic executed in the database (stored procedures). However, the more complex and expressive your domain model, the more you’ll benefit from using Hibernate; it shines when dealing with the full complexity of object/relational persistence.

Now that you have a (rudimentary) application design with a domain model, the next step is to implement it in Java. Let’s look at some of the things you need to consider.