JSP企业网站建设
附录 A
Understanding object/relational persistence
The approach to managing persistent data has been a key design decision in every software project we’ve worked on. Given that persistent data isn’t a new or unusual requirement for Java applications, you’d expect to be able to make a simple choice among similar, well-established persistence solutions. Think of web application frameworks (Jakarta Struts versus WebWork), GUI component frameworks (Swing versus SWT), or template engines (JSP versus Velocity). Each of the competing solutions has advantages and disadvantages, but they at least share the same scope and overall approach. Unfortunately, this isn’t yet the case with persistence technologies,where we see some wildly differing solutions to the same problem.
For several years, persistence has been a hot topic of debate in the Java community.Many developers don’t even agree on the scope of the problem. Is “persistence” a problem that is already solved by relational technology and extensions such as stored procedures, or is it a more pervasive problem that must be addressed by special Java component models such as EJB entity beans? Should we hand-code even the most primitive CRUD (create, read, update, delete) operations in SQL and JDBC, or should this work be automated? How do we achieve portability if every database management system has its own SQL dialect? Should we abandon SQL completely and adopt a new database technology, such as object database systems? Debate continues, but recently a solution called object/relational mapping (ORM) has met with increasing acceptance.
Hibernate is an open source ORM implementation.Hibernate is an ambitious project that aims to be a complete solution to the problem of managing persistent data in Java. It mediates the application’s interaction with a relational database, leaving the developer free to concentrate on the business problem at hand. Hibernate is an non-intrusive solution. By this we mean you aren’t required to follow many Hibernate-specific rules and design patterns when writing your business logic and persistent classes; thus, Hibernate integrates smoothly with most new and existing applications and doesn’t require disruptive changes to the rest of the application.
This article is about Hibernate. We’ll cover basic and advanced features and describe some recommended ways to develop new applications using Hibernate.Often, these recommendations won’t be specific to Hibernate—sometimes they will be our ideas about the best ways to do things when working with persistent data, explained in the context of Hibernate. Before we can get started with Hibernate,however, you need to understand the core problems of object persistence and object/relational mapping. This chapter explains why tools like Hibernate are needed.
First, we define persistent data management in the context of object-oriented applications and discuss the relationship of SQL, JDBC, and Java, the underlying technologies and standards that Hibernate is built on. We then discuss the socalled object/relational paradigm mismatch and the generic problems we encounter in object-oriented software development with relational databases. As this list of problems grows, it becomes apparent that we need tools and patterns to minimize the
time we have to spend on the persistence-related code of our applications. After we look at alternative tools and persistence mechanisms, you’ll see that ORM is the best available solution for many scenarios. Our discussion of the advantages and drawbacks of ORM gives you the full background to make the best decision when picking a persistence solution for your own project.
What is persistence?
Almost all applications require persistent data. Persistence is one of the fundamental concepts in application development. If an information system didn’t preserve data entered by users when the host machine was powered off, the system would be of little practical use. When we talk about persistence in Java, we’re normally talking about storing data in a relational database using SQL. We start by taking a brief look at the technology and how we use it with Java. Armed with that information, we then continue our discussion of persistence and how it’s implemented in object-oriented applications.
Relational databases
You, like most other developers, have probably worked with a relational database.In fact, most of us use a relational database every day. Relational technology is a known quantity. This alone is sufficient reason for many organizations to choose it. But to say only this is to pay less respect than is due. Relational databases are so entrenched not by accident but because they’re an incredibly flexible and robust approach to data management.
A relational database management system isn’t specific to Java, and a relational database isn’t specific to a particular application. Relational technology provides a way of sharing data among different applications or among different technologies that form part of the same application (the transactional engine and the reporting engine, for example). Relational technology is a common denominator of many disparate systems and technology platforms. Hence, the relational data model is often the common enterprise-wide representation of business entities. Relational database management systems have SQL-based application programming interfaces; hence we call today’s relational database products SQL database management systems or, when we’re talking about particular systems, SQL databases.
Understanding SQL
To use Hibernate effectively, a solid understanding of the relational model and SQL is a prerequisite. You’ll need to use your knowledge of SQL to tune the performance of your Hibernate application. Hibernate will automate many repetitive coding tasks, but your knowledge of persistence technology must extend beyond Hibernate itself if you want take advantage of the full power of modern SQL databases.Remember that the underlying goal is robust, efficient management of persistent data.Let’s review some of the SQL terms used in this book. You use SQL as a data definition language (DDL) to create a database schema with CREATE and ALTER statements. After creating tables (and indexes, sequences, and so on), you use SQL as a data manipulation language (DML). With DML, you execute SQL operations that manipulate and retrieve data. The manipulation operations include insertion, update, and deletion. You retrieve data by executing queries with restriction, projection, and join operations (including the Cartesian product). For efficient reporting, you use SQL to group, order, and aggregate data in arbitrary ways. You can even nest SQL statements inside each other; this technique is called subselecting. You have probably used SQL for many years and are familiar with the basic operations and statements written in this language. Still, we know from our own experience that SQL is sometimes hard to remember and that some terms vary in usage. To understand this book, we have to use the same terms and concepts; so, we advise you to read appendix A if any of the terms we’ve mentioned are new or unclear.SQL knowledge is mandatory for sound Java database application development.If you need more material, get a copy of the excellent book SQL Tuning by Dan Tow
Also read An Introduction to Database Systems [Date 2004] for the theory, concepts, and ideals of (relational) database systems. Although the relational database is one part of ORM, the other part, of course, consists of the objects in your Java application that need to be persisted to the database using SQL.
Using SQL in Java
When you work with an SQL database in a Java application, the Java code issues SQL statements to the database via the Java DataBase Connectivity (JDBC) API. The SQL itself might have been written by hand and embedded in the Java code, or it might have been generated on the fly by Java code. You use the JDBC API to bind arguments to query parameters, initiate execution of the query, scroll through the query result table, retrieve values from the result set, and so on. These are lowlevel data access tasks; as application developers, we’re more interested in the business problem that requires this data access. It isn’t clear that we should be concerning ourselves with such tedious, mechanical details.What we’d really like to be able to do is write code that saves and retrieves complex objects—the instances of our classes—to and from the database, relieving us of this low-level drudgery.Since the data access tasks are often so tedious, we have to ask: Are the relational data model and (especially) SQL the right choices for persistence in objectoriented applications? We answer this question immediately: Yes! There are many reasons why SQL databases dominate the computing industry. Relational database management systems are the only proven data management technology and are almost always a requirement in any Java project.However, for the last 15 years, developers have spoken of a paradigm mismatch.This mismatch explains why so much effort is expended on persistence-related concerns in every enterprise project. The paradigms referred to are object modeling and relational modeling, or perhaps object-oriented programming and SQL. Let’s begin our exploration of the mismatch problem by asking what persistence means in the context of object-oriented application development. First we’ll widen the simplistic definition of persistence stated at the beginning of this section to a broader, more mature understanding of what is involved in maintaining and using persistent data.
Persistence in object-oriented applications
In an object-oriented application, persistence allows an object to outlive the process that created it. The state of the object may be stored to disk and an object with the same state re-created at some point in the future.This application isn’t limited to single objects—entire graphs of interconnected objects may be made persistent and later re-created in a new process. Most objects aren’t persistent; a transient object has a limited lifetime that is bounded by the life of the process that instantiated it. Almost all Java applications contain a mix of persistent and transient objects; hence we need a subsystem that manages our persistent data.Modern relational databases provide a structured representation of persistent data, enabling sorting, searching, and aggregation of data. Database management systems are responsible for managing concurrency and data integrity; they’re
responsible for sharing data between multiple users and multiple applications. A database management system also provides data-level security. When we discuss persistence in this book, we’re thinking of all these things:
■ Storage, organization, and retrieval of structured data
■ Concurrency and data integrity
■ Data sharing
In particular, we’re thinking of these problems in the context of an object-oriented application that uses a domain model.An application with a domain model doesn’t work directly with the tabular representation of the business entities; the application has its own, object-oriented model of the business entities. If the database has ITEM and BID tables, the Java application defines Item and Bid classes.Then, instead of directly working with the rows and columns of an SQL result set, the business logic interacts with this object-oriented domain model and its runtime realization as a graph of interconnected objects. The business logic is never executed in the database (as an SQL stored procedure), it’s implemented in Java. This allows business logic to make use of sophisticated object-oriented concepts such as inheritance and polymorphism. For example, we could use wellknown design patterns such as Strategy, Mediator, and Composite [GOF 1995], all of which depend on polymorphic method calls. Now a caveat: Not all Java applications are designed this way, nor should they be. JDBC RowSet (Sun JCP, JSR 114) makes CRUD operations even easier. Working with a tabular , the domain model helps to improve code reuse and maintainability significantly. We focus on applications with a domain model in this book, since Hibernate and ORM in general are most relevant to this kind of application. If we consider SQL and relational databases again, we finally observe the mismatch between the two paradigms. SQL operations such as projection and join always result in a tabular representation of the resulting data. This is quite different than the graph of interconnected objects used to execute the business logic in a Java application! These are fundamentally different models, not just different ways of visualizing the same model. With this realization, we can begin to see the problems—some well understood and some less well understood—that must be solved by an application that combines both data representations: an object-oriented domain model and a persistent
relational model. Let’s take a closer look.
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... 下一页 >>