Java持久层API（JPA）开发指南

需积分: 0 22 浏览量更新于2024-07-22 收藏 5.04MB PDF 举报

"JPA开发指南" 本书《Apress.Pro.JPA.2.2nd.Edition.Oct.2013》是Java Persistence API（JPA）开发的必备指南，旨在帮助开发者快速入门学习JPA技术。本书共分为十五章，涵盖了JPA的基本概念、企业应用、对象关系映射、集合映射、实体管理器、查询语言、criteria API、advanced对象关系映射、高级查询、其他高级主题、XML映射文件、打包和部署、测试等方面的内容。 Chapter 1：Introduction 本章节介绍了企业应用程序的定义和特点，并讨论了数据存储和处理的重要性。作者还介绍了JPA的历史发展和技术架构。知识点： * 企业应用程序的定义和特点 * 数据存储和处理的重要性 * JPA的历史发展和技术架构 Chapter 2：Getting Started 本章节介绍了JPA的基本概念，包括实体、实体管理器、持久化单元和查询语言。作者还提供了JPA的开发环境设置和基本配置。知识点： * JPA的基本概念：实体、实体管理器、持久化单元和查询语言 * JPA开发环境设置和基本配置 Chapter 3：Enterprise Applications 本章节讨论了企业应用程序的架构和设计，包括 Presentation Layer、Business Logic Layer 和Data Access Layer。作者还介绍了JPA在企业应用程序中的应用。知识点： * 企业应用程序的架构和设计 * JPA在企业应用程序中的应用 Chapter 4：Object-Relational Mapping 本章节深入探讨了JPA的对象关系映射机制，包括基本映射、继承映射和关联映射。作者还提供了实例代码来演示对象关系映射的实现。知识点： * JPA的对象关系映射机制 * 基本映射、继承映射和关联映射 Chapter 5：Collection Mapping 本章节介绍了JPA的集合映射机制，包括基本集合映射和嵌套集合映射。作者还提供了实例代码来演示集合映射的实现。知识点： * JPA的集合映射机制 * 基本集合映射和嵌套集合映射 Chapter 6：EntityManager 本章节讨论了JPA的实体管理器，包括实体管理器的创建、实体的 CRUD 操作和事务管理。作者还提供了实例代码来演示实体管理器的使用。知识点： * JPA的实体管理器 * 实体管理器的创建、实体的 CRUD 操作和事务管理 Chapter 7：Using Queries 本章节介绍了JPA的查询语言，包括基本查询、命名查询和 native 查询。作者还提供了实例代码来演示查询语言的使用。知识点： * JPA的查询语言 * 基本查询、命名查询和 native 查询 Chapter 8：Query Language 本章节深入探讨了JPA的查询语言，包括查询的语法、查询的执行和查询的优化。作者还提供了实例代码来演示查询语言的使用。知识点： * JPA的查询语言语法 * 查询的执行和优化 Chapter 9：Criteria API 本章节介绍了JPA的Criteria API，包括 Criteria 查询的创建和执行。作者还提供了实例代码来演示Criteria API的使用。知识点： * JPA的Criteria API * Criteria 查询的创建和执行 Chapter 10：Advanced Object-Relational Mapping 本章节讨论了JPA的高级对象关系映射机制，包括继承映射、关联映射和嵌套映射。作者还提供了实例代码来演示高级对象关系映射的实现。知识点： * JPA的高级对象关系映射机制 * 继承映射、关联映射和嵌套映射 Chapter 11：Advanced Queries 本章节讨论了JPA的高级查询机制，包括子查询、关联查询和分组查询。作者还提供了实例代码来演示高级查询的实现。知识点： * JPA的高级查询机制 * 子查询、关联查询和分组查询 Chapter 12：Other Advanced Topics 本章节讨论了JPA的其他高级主题，包括二级缓存、事件监听器和JPA的Best Practices。作者还提供了实例代码来演示其他高级主题的实现。知识点： * JPA的二级缓存 * 事件监听器 * JPA的Best Practices Chapter 13：XML Mapping Files 本章节介绍了JPA的XML映射文件，包括映射文件的结构和映射文件的使用。作者还提供了实例代码来演示XML映射文件的使用。知识点： * JPA的XML映射文件 * 映射文件的结构和使用 Chapter 14：Packaging and Deployment 本章节讨论了JPA的打包和部署，包括JPA的打包方式和部署到应用服务器。作者还提供了实例代码来演示打包和部署的实现。知识点： * JPA的打包方式 * 部署到应用服务器 Chapter 15：Testing 本章节介绍了JPA的测试，包括单元测试和集成测试。作者还提供了实例代码来演示测试的实现。知识点： * JPA的单元测试 * 集成测试本书《Apress.Pro.JPA.2.2nd.Edition.Oct.2013》是一本非常详细和系统的JPA开发指南，涵盖了JPA的基本概念、企业应用、对象关系映射、集合映射、实体管理器、查询语言、criteria API、advanced对象关系映射、高级查询、其他高级主题、XML映射文件、打包和部署、测试等方面的内容，对于JPA开发者来说是一个非常有价值的参考书籍。

Chapter 1 ■ IntroduCtIon

Non-intrusiveness

The persistence API exists as a separate layer from the persistent objects. The persistence API is called by the

application business logic, is passed the persistence objects, and is instructed to operate upon them. So even though

the application must be aware of the persistence API because it has to call into it, the persistent objects themselves

need not be aware. Because the API does not intrude upon the code in the persistent object classes, it’s called

non-intrusive persistence.

Some people are under the misconception that non-intrusive persistence means that objects magically get

persisted, the way that object databases of yesteryear used to do when a transaction got committed. This is sometimes

called transparent persistence and is an incorrect notion that is even more irrational when you think about querying.

You need to have some way of retrieving the objects from the data store. This requires a separate API object and, in

fact, some object databases required that users invoke special Extent objects to issue queries. Applications absolutely

need to manage their persistent objects in very explicit ways, and they require a designated API to do it.

Object Queries

A powerful query framework offers the ability to query across entities and their relationships without having to use

concrete foreign keys or database columns. Queries may be expressed in JP QL, a query language that is modeled after

SQL for its familiarity but is not tied to the database schema, or defined using the criteria API. Queries use a schema

abstraction that is based on the entity model as opposed to the columns in which the entity is stored. Java entities and

their attributes are used as the query schema, so knowledge of the database-mapping information is not required. The

queries will eventually get translated by the JPA implementation into the SQL appropriate for the target database and

executed on the database.

A query may be defined statically in metadata or created dynamically by passing query criteria when constructing

it. It is also possible to escape to SQL if a special query requirement exists that cannot be met by the SQL generation

from the persistence framework. These queries can return results in the form of entities, projections of specific entity

attributes, or even aggregate function values, amongst other options. JPA queries are valuable abstractions that enable

querying across the Java domain model instead of across concrete database tables.

Mobile Entities

Client/server and web applications and other distributed architectures are clearly the most popular types of

applications in a connected world. To acknowledge this fact means acknowledging that persistent entities must be

mobile in the network. Objects must be able to be moved from one Java Virtual Machine (JVM) to another and then

back again, and must still be usable by the application.

Objects that leave the persistence layer are called detached. A key feature of the persistence model is the ability

to change detached entities and then reattach them upon their return to the originating JVM. The detachment model

provides a way of reconciling the state of an entity being reattached with the state that it was in before it became

detached. This allows entity changes to be made offline while still maintaining entity consistency in the face of

concurrency.

Simple Configuration

There are a great number of persistence features that the specification has to offer and that we will explain in the

chapters of this book. All the features are configurable through the use of annotations, XML, or a combination of

the two. Annotations offer ease of use that is unparalleled in the history of Java metadata. They are convenient to

write and painless to read, and they make it possible for beginners to get an application going quickly and easily.

Configuration can also be done in XML for those who like XML or want to externalize the metadata from the code.

Chapter 1 ■ IntroduCtIon

Of greater significance than the metadata language is the fact that JPA makes heavy use of defaults. This means

that no matter which method is chosen, the amount of metadata that will be required just to get running is the

absolute minimum. In some cases, if the defaults are good enough, almost no metadata will be required at all.

Integration and Testability

Multitier applications hosted on an application server have become the de facto standard for application

architectures. Testing on an application server is a challenge that few relish. It can bring pain and hardship, and it is

often prohibitive to practicing unit testing and white box testing.

This is solved by defining the API to work outside as well as inside the application server. Although it is not as

common a use case, applications that do run on two tiers (the application talking directly to the database tier) can use

the persistence API without the existence of an application server at all. The more common scenario is for unit tests

and automated testing frameworks that can be run easily and conveniently in Java SE environments.

With the Java Persistence API it is now possible to write server-integrated persistence code and be able to reuse

it for testing outside the server. When running inside a server container, all the benefits of container support and

superior ease of use apply, but with a few changes and a little bit of test framework support the same application can

also be configured to run outside the container.

Summary

This chapter presented an introduction to the Java Persistence API. We began with an introduction to the primary

problem facing developers trying to use object-oriented domain models in concert with a relational database: the

impedance mismatch. To demonstrate the complexity of bridging the gap, we presented three small object models

and nine different ways to represent the same information. We explored each a little and discussed how mapping

objects to different table configurations can cause differences, not only in the way data evolves in the database but

also how expensive the resulting database operations are and how the application performs.

We then presented an overview of some of the proprietary solutions and the current standards for persistence,

looking at JDBC, EJB, and JDO. In each case, we looked at the evolution of the standard and where it fell short. You

gained some general insights on particular aspects of the persistence problem that were learned along the way.

We concluded the chapter with a brief look at JPA. We looked at the history of the specification and the vendors

who came together to create it. We then looked at the role it plays in enterprise application development and gave an

introduction to some of the features offered by the specification.

In the next chapter, you will get your feet wet with JPA by taking a whirlwind tour of the basics and building

a simple application in the process.

Chapter 2

Getting Started

One of the main goals of JPA was that it should be simple to use and easy to understand. Although its problem domain

cannot be trivialized or watered down, the technology that enables developers to deal with it can be straightforward

and intuitive. In this chapter, we will show how effortless it can be to develop and use entities.

We will start by describing the basic characteristics of entities. We’ll define what an entity is and how to create,

read, update, and delete it. We’ll also introduce entity managers and how they are obtained and used. Then we’ll

take a quick look at queries and how to specify and execute a query using the EntityManager and Query objects. The

chapter will conclude by showing a simple working application that runs in a standard Java SE environment and

demonstrates all of the example code in action.

Entity Overview

The entity is not a new thing in data management. In fact, entities have been around longer than many programming

languages and certainly longer than Java. They were first introduced by Peter Chen in his seminal paper on

entity-relationship modeling.

He described entities as things that have attributes and relationships. The expectation

was that the attributes and relationships would be persisted in a relational database.

Even now, the definition still holds true. An entity is essentially a noun, or a grouping of state associated together

as a single unit. It may participate in relationships to any number of other entities in a number of standard ways. In the

object-oriented paradigm, we would add behavior to it and call it an object. In JPA, any application-defined object can

be an entity, so the important question might be this: What are the characteristics of an object that has been turned

into an entity?

Persistability

The first and most basic characteristic of entities is that they are persistable. This generally just means that they can be

made persistent. More specifically, it means that their state can be represented in a data store and can be accessed at a

later time, perhaps well after the end of the process that created it.

You could call them persistent objects, and many people do, but it is not technically correct. Strictly speaking,

a persistent object becomes persistent the moment it is instantiated in memory. If a persistent object exists, then by

definition it is already persistent.

An entity is persistable because it can be saved in a persistent store. The difference is that it is not automatically

persisted, and that in order for it to have a durable representation the application must actively invoke an API

method to initiate the process. This is an important distinction because it leaves control over persistence firmly in

Peter P. Chen, “The entity-relationship model—toward a unified view of data,” ACM Transactions on Database Systems 1,

no. 1 (1976): 9–36.

Chapter 2 ■ GettinG Started

the hands of the application. The application has the flexibility to manipulate data and perform business logic on the

entity, making it persistent only when the application decides it is the right time. The lesson is that entities may be

manipulated without necessarily being persisted, and it is the application that decides whether they are or not.

Identity

Like any other Java object, an entity has an object identity, but when it exists in the database it also has a persistent

identity. Object identity is simply the differentiation between objects that occupy memory. Persistent identity, or an

identifier, is the key that uniquely identifies an entity instance and distinguishes it from all the other instances of the

same entity type. An entity has a persistent identity when there exists a representation of it in the data store; that is, a

row in a database table. If it is not in the database, then even though the in-memory entity may have its identity set in

a field, it does not have a persistent identity. The entity identifier, then, is equivalent to the primary key in the database

table that stores the entity state.

Transactionality

Entities might be called quasi-transactional. Although they can be created, updated, and deleted in any context, these

operations are normally done within the context of a transaction

because a transaction is required for the changes to

be committed in the database. Changes made to the database either succeed or fail atomically, so the persistent view

of an entity should indeed be transactional.

In memory, it is a slightly different story in the sense that entities may be changed without the changes ever

being persisted. Even when enlisted in a transaction, they may be left in an undefined or inconsistent state in the

event of a rollback or transaction failure. The in-memory entities are simple Java objects that obey all of the rules and

constraints that are applied by the Java Virtual Machine (JVM) to other Java objects.

Granularity

Finally, a good way to show what entities are is to describe what they are not. They are not primitives, primitive

wrappers, or built-in objects with single-dimensional state. These are no more than scalars and do not have any

inherent semantic meaning to an application. A string, for example, is too fine-grained an object to be an entity

because it does not have any domain-specific connotation. Rather, a string is well-suited and very often used as a type

for an entity attribute and given meaning according to the entity attribute that it is typing.

Entities are meant to be fine-grained objects that have a set of aggregated state that is normally stored in a single

place, such as a row in a table, and typically have relationships to other entities. In the most general sense, they are

business domain objects that have specific meaning to the application that accesses them.

While it is certainly true that entities may be defined in exaggerated ways to be as fine-grained as storing a single

string or coarse-grained enough to contain 500 columns’ worth of data, JPA entities were definitely intended to be

on the smaller end of the granularity spectrum. Ideally, entities should be designed and defined as fairly lightweight

objects of a size comparable to that of the average Java object.

Entity Metadata

In addition to its persistent state, every JPA entity has some associated metadata (even if a very small amount) that

describes it. This metadata may exist as part of the saved class file or it may be stored external to the class, but it is not

persisted in the database. It enables the persistence layer to recognize, interpret, and properly manage the entity from

the time it is loaded through to its runtime invocation.

In most cases, this is a requirement, but in certain configurations the transaction might not be started until after the operation.

Chapter 2 ■ GettinG Started

The metadata that is actually required for each entity is minimal, rendering entities easy to define and use.

However, like any sophisticated technology with its share of switches, levers, and buttons, there is also the possibility

to specify much, much more metadata than is required. It may be extensive amounts, depending upon the application

requirements, and may be used to customize every detail of the entity configuration or state mappings.

Entity metadata may be specified in two ways: annotations or XML. Each is equally valid, but the one that you use

will depend upon your development preferences or process.

Annotations

Annotation metadata is a language feature introduced in Java SE 5 that allows structured and typed metadata to be

attached to the source code. Although annotations are not required by JPA, they are a convenient way to learn and

use the API. Because annotations co-locate the metadata with the program artifacts, it is not necessary to escape to an

additional file and a special language (XML) just to specify the metadata.

Annotations are used throughout both the examples and the accompanying explanations in this book. All the JPA

annotations that are shown and described (except in Chapter 3, which talks about Java EE annotations) are defined

in the javax.persistence package. Example code snippets can be assumed to have an implicit import of the form

import javax.persistence.*;.

XML

For those who prefer to use traditional XML, this option is still available. It should be fairly straightforward to switch

to using XML descriptors after having learned and understood the annotations because the XML has mostly been

patterned after the annotations. Chapter 13 describes how to use XML to specify or override entity mapping metadata.

Configuration by Exception

The notion of configuration by exception means that the persistence engine defines defaults that apply to the majority

of applications and that users need to supply values only when they want to override the default value. In other words,

having to supply a configuration value is an exception to the rule, not a requirement.

Configuration by exception is ingrained in JPA and contributes strongly to its usability. Most configuration values

have defaults, rendering the metadata that does have to be specified more relevant and concise.

The extensive use of defaults and the ease of use that it brings to configuration come at a price, however. When

defaults are embedded into the API and do not have to be specified, then they are not visible or obvious to users.

This can make it possible for users to be unaware of the complexity of developing persistence applications, making it

harder to debug or to change the behavior when it becomes necessary.

Defaults are not meant to shield users from the often complex issues surrounding persistence. They are meant

to allow a developer to get started easily and quickly with something that will work and then iteratively improve and

implement additional functionality as the complexity of their application increases. Even though the defaults may

be what you want to have happen most of the time, it is still important for developers to be familiar with the default

values that are being applied. For example, if a table name default is being assumed, it is important to know what table

the runtime is expecting, or if schema generation is used, what table will be generated.

For each of the annotations we will also discuss the default value so that it is clear what will be applied if the

annotation is not specified. We recommend that you remember these defaults as you learn them. After all, a default

value is still part of the configuration of the application; it is just really easy to configure!

Creating an Entity

Regular Java classes are easily transformed into entities simply by annotating them. In fact, by adding a couple of

annotations, almost any class with a no-arg constructor can become an entity.

剩余496页未读，继续阅读

Tieniu521

粉丝: 0
资源: 1

Java持久层API（JPA）开发指南

《Apress.Pro.Expression.Blend.4》：精通微软WPF与Silverlight开发的全面指南

精通Web前端：Apress.Pro JavaScript实战指南

《Pro ASP.NET MVC 2 Framework 2nd Edition》：高性能微软平台Web应用开发指南

Apress.Pro.Django.2nd.Edition.Jul.2013

[Apress.J2EE系列].Apress.Pro.JSP.2.4th.Edition.Dec.2005

Apress.Pro.2nd.Edition

Apress.Pro.Power.BI.Desktop.2nd.Edition

Apress.Pro.HTML5.Programming.2nd.Edition

Apress.Pro.Business.Applications.with.Silverlight.5.2nd.Edition.2012

Apress.Pro.Business.Applications.with.Silverlight.5.2nd.Edition.Feb.2012

最新资源