精通JPA 2：企业级应用指南

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

身份认证购VIP最低享 7 折!

30元优惠券

"Pro JPA 2版是一本详细介绍JPA2的权威书籍，读者阅读后可以深入理解JPA的架构和使用方法。本书涵盖了从基础到高级的各种主题，包括对象关系映射、集合映射、实体管理器、查询语言、标准查询API、高级ORM策略以及打包和部署等内容。" 在Java平台上，Java Persistence API（JPA）是一种用于管理关系数据库中的数据的标准API，它简化了企业级应用的数据存储和检索过程。JPA2是其一个重要版本，引入了许多增强功能，提高了开发效率和灵活性。本书"Pro JPA 2版"分为多个章节，逐步引导读者深入理解JPA的各个方面： 1. **Chapter 1: Introduction** - 引言部分可能介绍了JPA的基本概念，以及为什么在企业应用中选择JPA作为数据持久化框架的原因。它可能概述了JPA的优势，如对象关系映射（ORM）的便利性和与Java EE平台的集成。 2. **Chapter 2: Getting Started** - 这一章可能是关于如何设置JPA环境，创建第一个JPA项目的指导，包括配置persistence.xml文件和基本的实体类定义。 3. **Chapter 3: Enterprise Applications** - 本章可能探讨了JPA在实际企业应用中的角色，包括如何处理事务、并发控制和性能优化。 4. **Chapter 4: Object-Relational Mapping** - JPA的核心在于ORM，这一章详细介绍了如何将Java对象映射到数据库表，包括字段映射、主键生成策略和继承结构的映射。 5. **Chapter 5: Collection Mapping** - 针对多对一、一对多、多对多的关系映射进行深入讲解，如何处理关联集合和集合的懒加载策略。 6. **Chapter 6: EntityManager** - 实体管理器是JPA的主要工作接口，这部分可能涉及实体的生命周期管理，如持久化、查找、更新和删除操作，以及实体状态的管理。 7. **Chapter 7: Using Queries** - 这一章可能涵盖了JPA的查询机制，包括JPQL（Java Persistence Query Language）的基本用法，以及如何执行动态查询。 8. **Chapter 8: Query Language** - 对JPQL的深入解析，可能包含复杂的联接、子查询和聚合函数的使用。 9. **Chapter 9: Criteria API** - JPA2引入的Criteria API提供了一种类型安全的方式来构建动态查询，这一章可能详细讲解了它的用法和优势。 10. **Chapter 10: Advanced Object-Relational Mapping** - 探讨更高级的ORM技巧，如嵌入式对象、转换和事件监听器。 11. **Chapter 11: Advanced Queries** - 讨论更复杂的查询策略，如分页、排序和性能调优。 12. **Chapter 12: Other Advanced Topics** - 可能包含了JPA2的其他特性，如二进制数据处理、定时任务和缓存策略。 13. **Chapter 13: XML Mapping Files** - 解释了如何使用XML文件来替代注解进行映射配置，以及XML与注解的混合使用。 14. **Chapter 14: Packaging and Deployment** - 讲解了如何打包和部署包含JPA的应用，可能包括不同容器的集成和部署配置。 15. **Chapter 15: Testing** - 最后一章可能涵盖如何编写测试用例，确保JPA应用的正确性和性能。此外，书中的附录和索引提供了方便的参考材料，帮助读者快速定位所需信息。通过阅读此书，开发者能够全面掌握JPA2的使用，提升开发高效、可靠的企业级应用程序的能力。

资源详情

资源推荐

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.

www.it-ebooks.info

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.

www.it-ebooks.info

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.

www.it-ebooks.info

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.

www.it-ebooks.info

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.

www.it-ebooks.info

剩余496页未读，继续阅读

neihcop

粉丝: 0
资源: 29

精通JPA 2：企业级应用指南

Pro JPA2 精通JPA2

Pro JPA2 书籍 代码

jpa和spring data jpa

springboo2 jpa clickhouse

spring-boot-starter-data-jpa版本

jpa findby 报错找不到方法

jpa JpaRepository join

jpa 本地接口 findBy报错 NoSuchMethodError

jpa 多层嵌套一对多_JPA2中CriteriaBuilder查询多组条件or与and组合问题

jpa JpaRepository 返回Dto

springdatajpa依赖

mybatisX 怎么生成jpa

MyBatisX 生成jpa实体

用什么插件可以生成jpa

我的数据库是oracle的，使用的是JPA ， 为什么执行SQL是用的JPA 的h2

jpa自定义sql语法

springboot3 JpaRepository

spring data jpa介绍

在java jpa中

SpringJpa中JpaSpecificationExecutor和JpaRepository是什么

最新资源

Pro JPA2 书籍代码

我的数据库是oracle的，使用的是JPA ，为什么执行SQL是用的JPA 的h2