NHibernate实战：.NET ORM框架详解

需积分: 9 196 浏览量更新于2024-07-27 收藏 1.94MB PDF 举报

"NHibernate in Action" 是一本专注于.NET平台上的对象关系映射（ORM）框架NHibernate的开发指南。本书由Manning Publications出版，并在2008年发行。书中内容涵盖NHibernate的基础到高级应用，旨在帮助开发者理解和熟练使用这个强大的ORM工具。 NHibernate是一个开源的ORM框架，它允许.NET开发者将业务对象与数据库表进行映射，从而避免了直接编写SQL语句，简化了数据访问层的代码。这本书深入浅出地介绍了如何在C#编程环境中运用NHibernate，以实现高效、灵活的数据持久化。书中的章节内容包括： 1. 对象关系持久化在.NET中的应用：讲解了ORM的基本概念以及在.NET环境下的意义和价值。 2. 初识NHibernate：介绍如何安装和配置NHibernate，以及创建第一个简单的应用程序。 3. 编写和映射类：详细阐述如何定义领域模型，以及如何将这些类映射到数据库表上。 4. 使用持久化对象：探讨如何创建、读取、更新和删除（CRUD）操作，以及对象的状态管理。 5. 事务、并发和缓存：讲解如何处理数据库事务，解决并发问题，以及使用NHibernate的缓存机制提高性能。 6. 高级映射概念：介绍更复杂的映射技巧，如多对一、一对多、多对多的关系映射，以及自定义类型映射等。 7. 有效检索对象：探讨如何优化查询，使用HQL（Hibernate Query Language）和 Criteria API进行高效检索。 8. 开发NHibernate应用程序：提供实际项目中的最佳实践，指导读者如何在实际开发流程中整合NHibernate。 9. 编写真实的领域模型：针对真实世界业务场景，展示如何设计和实现复杂的领域模型。 10. 高级持久化技术：涵盖了高级话题，如事件监听、定制化策略和高级查询技术。此外，书中有两个附录，分别介绍了SQL基础和NHibernate映射属性的更多细节，以帮助读者更好地理解和掌握NHibernate的全貌。通过阅读本书，开发者可以深入了解NHibernate的工作原理，提升在.NET环境中处理数据持久化的技能，同时也能更好地利用ORM技术来简化数据库交互，提高开发效率。在线论坛（http://www.manning-sandbox.com/forum.jspa?forumID=295）为读者提供了提问和讨论的平台，作者也会在此回应评论和修正，确保内容的准确性和时效性。

Please post comments or corrections to the Author online forum at

http://www.manning-sandbox.com/forum.jspa?forumID=295

performed by the user are treated as if they were a single bigger business transaction (a unit). You will learn in

this section that NHibernate makes it much easier to achieve. Let’s take another example to better illustrate this

concept.

Popular media players allow you to rate the songs you hear and later sort them based on your rating. This

means that your ratings are persisted. When you open a list of songs, you listen and rate them one by one.

When is persistence supposed to take place?

The first solution, which may come to your mind, is to persist the rating when it is entered by the user. But

this is very inefficient: The user may change it many times and this persistence will be done separately for each

song. Though, this approach is certainly safer if you expect this application to crash at any moment.

What we can do is let the user rate all songs of the list, and when he closes it, then we persists all ratings.

The process of rating these songs can be called a conversation.

Let see how it works and what its benefits are.

The Unit of Work pattern

When working with a relational database, we tend to think of commands: saving or loading. But an application

can perform operations involving many entities. When these entities are loaded or saved depends on the

context.

For example, if you want to load the last item created by a user, you must first save this user (and his

collection of items), then you can run a query retrieving this item. If you forget to save the user, you will start

getting hardly-detectable bugs.

The Identity Map pattern

A pattern called Identity Map is used by NHibernate to make sure that this item’s user is the same

object as the user you had before loading this item (as long as you are working in the same

transaction). You will learn more about the concept of identity in chapter 3, section 3.5,

“Understanding object identity”.

Now, imagine that you are involved in a very complex conversation. Manually tracking the entities to save or

delete, and making sure that you load each entity only once can be a nightmare.

A Unit of Work is a pattern followed by NHibernate to solve this problem and ease the implementation of

conversations. Note that, we cover conversations in chapter 5 and we implement them in chapter 10.

You can create entities and associate them to NHibernate, and then it keeps track of all loading and may

save any change only when required. At the end of the transaction, it figures out and applies all changes in

their correct order.

Transparent persistence and lazy loading

Because NHibernate keeps track of all entities, it can greatly simplify your application and increase its

performance. Here are two simple examples:

When working on an item of our auction application, a user can add, modify or delete its bids. It would be

painful to manually track these changes one by one. Instead, we can use the feature of NHibernate called

transparent persistence: You can ask NHibernate to save all changes in the collection of bids when the item is

persisted. It will automatically figure out which CRUD operations must be executed.

Now, if you want to modify a user, you will load, change and persist it. But what about the collection of

items that this user has? Should you load these items or leave the collection un-initialized? Loading the items

would be inefficient, but leaving the collection un-initialized will limit our ability to manipulate the user.

Licensed to Jason Wilden <jasonwilden@internode.on.net>

Please post comments or corrections to the Author online forum at

http://www.manning-sandbox.com/forum.jspa?forumID=295

NHibernate support a feature called lazy loading to solve this problem. Basically, when loading the user,

you can decide between loading the items or not. If you choose not to do so, this collection will be

transparently initialized when you need it.

There are many implications in using these features; we will progressively cover them in this book.

Caching

Tracking entities implies keeping their references in some place. NHibernate uses what is called a cache. This

cache is indispensable to implement the Unit of Work pattern. However, it can also make applications more

efficient. We deeply cover the concept of caching in chapter 5, section 5.3 “Caching theory and practice”.

A cache is used by the identity map of NHibernate to avoid loading an entity many times. And this cache

can be shared by transactions and even applications.

Let’s say that we build a website for our auction application. Our visitors may be interested by some items.

Without a cache, these items will be loaded from the database each time a visitor wants to see it. With few

lines, we can ask NHibernate to cache these items and enjoy the performance gain.

1.3.3 Complex queries and ADO.NET Entity Framework

This is the last but not the least feature related to persistence. In section 1.2.5, we talked about CRUD

operations. We have discovered some features related to Create, Update and Delete (all related to the Unit of

Work pattern). Now, we are going to talk about Retrieve operations; that is searching and loading information.

We know that we can easily generate code to load an entity using its identifier (primary key in the context

of relational database). But in real-world applications, users rarely deal with identifiers; instead they use some

criteria to run a search and then pick the information they want.

Implementing a query engine

If you are familiar with SQL, you know that you can write very complex queries using the SELECT ...

FROM ... WHERE ...

construct. But if you work with business objects, you would then have to transform

the results of your SQL queries into entities. We already advertised the benefits of working with entities,

therefore it might make more sense to take advantage of those benefits even when querying the database .

Based on the fact that NHibernate can load and save entities, we can deduce that it knows how each entity

is mapped to the database. When we ask for an entity by it’s identifier, NHibernate knows how to find it. So,

we should be able to express a query using entity names and properties, and then NHibernate should be able to

convert that into a corresponding SQL query understood by the relational database.

NHibernate provides two query APIs: The first is called the Hibernate Query Language. HQL is similar to

SQL in many ways, but also has some useful object-oriented features. Note that you can query NHibernate

using plain old SQL, but as you will learn, using HQL offers several advantages.

The second query API is called the Query by Criteria API (QBC). It provides a set of type-safe classes to

build queries in your chosen .NET language. This means that if you’re using Visual Studio, you’ll benefit from

the inline error reporting and Intellisense™!

To give you a foretaste of the power of these APIs, we are going to build three simple queries. Firstly, here

is some HQL. It finds all bids for items, where the sellers name starts with the letter K:

from Bid bid

where bid.Item.Seller.Name like 'K%'

As you can see, it’s very easy to understand. If you want to write some SQL to do the same thing, you would

need something a little more verbose, along the lines of:

Licensed to Jason Wilden <jasonwilden@internode.on.net>

Please post comments or corrections to the Author online forum at

http://www.manning-sandbox.com/forum.jspa?forumID=295

select B.*

from BID B

inner join ITEM I on B.ITEM_ID = I.ITEM_ID

inner join USER U on I.AUTHOR_ID = U.USER_ID

where U.NAME like 'K%'

To illustrate the power of the Query by Criteria API, we will use an example derived from that shown in

chapter 8, section 8.5.1. This shows a method that allows us to find and load all users who are similar to an

example user, and who also have a bid item similar to a given example item:

public IList<User> FindUsersWithSimilarBidItem(User u, Item i) {

Example exampleUser =

Example.Create(u).EnableLike(MatchMode.Anywhere);

Example exampleItem =

Example.Create(i).EnableLike(MatchMode.Anywhere);

return GetSession().CreateCriteria(typeof(User))

.Add( exampleUser )

.CreateCriteria("Items")

.Add( exampleItem )

.List<User>();

}

Essentially, this method allows the developer to pass objects that represent the kind of Users we want

NHibernate to find and load. It creates two NHibernate

Example objects and uses the Query by Criteria API

to run the query and retrieve a list of users. The notion of example entity (here, example User and example

Item) is both powerful and elegant, as demonstrated below:

User u = new User();

Item I = new Item();

u.Name = "K";

i.State = ItemState.Active;

i.ApprovedBy = administratorUser;

List<User> result = FindUsersWithSimilarBidItem(u, i);

Here, we are using our FindUsersWithSimilarBidItem method to retrieve users whose names contain

‘K’ and who are selling an active bid Item, which has also been approved by the administrator. Quite a feat for

such little code! If you are new to this approach, you should find it somewhat unbelievable. Don’t even try to

implement this query using hand-coded SQL.

You can learn more about queries in Chapters 5 and 7. If you aren’t fully satisfied by these APIs, you may

also want to watch new upcoming developments that allow LINQ to be used with NHibernate.

ADO.NET Entity Framework

At the time of this writing, Microsoft is working on its Next-Generation Data Access technology which

introduces a number of interesting and exciting innovations. You may feel that this technology will soon

replace NHibernate, but this is very unlikely. Let’s see why.

Perhaps the most exciting new feature is a powerful query framework code-named LINQ. LINQ extends

your favorite .NET language so that you can run queries against various types of data source, without having to

embed query strings in your code. So, when querying a relational database, you can do something like this:

//C# LINQ example, look ma no strings!

IEnumerable users = from u in Users

where u.Forename.StartsWith("K")

order by user.Forename descending

select u;

As you can see, the queries are type-safe and allow you to take advantage of many .NET language features.

One key aspect of LINQ is that it gives us a declarative way of working with data, so we can express what we

want in simple terms rather than typing lots of for-each loops. Furthermore, we can benefit from helpful IDE

Licensed to Jason Wilden <jasonwilden@internode.on.net>

Please post comments or corrections to the Author online forum at

http://www.manning-sandbox.com/forum.jspa?forumID=295

capabilities such as auto-completion and parameter assistance. This is a big win for everybody. Because LINQ

is designed to be extensible, other tools such as NHibernate are able to integrate with this technology and

benefit from it greatly. At the time of publishing, there is some very promising work in progress for a LINQ to

NHibernate project. At the time of writing, Manning are working on the “LINQ in Action” book, it sounds

very interesting!

Microsoft is also working on a framework currently called LINQ to Entities, which aims to provide

developers with an object-relational mapping framework not completely unlike NHibernate. This is as a good

step forward because Microsoft will promote the DataSet less often, and also start educating and promoting the

benefits of object-relational mapping tools. Another project called LINQ over DataSet greatly improves the

query capabilities of DataSet, but it doesn't solve many other issues discussed in this chapter.

All these technologies will take a little time to mature. There are still many unanswered questions, such as

how extensible this framework will be? Will it support most popular RDBMSs or just SQL Server? Will it be

easy to work with legacy database schemas? The fact is, no framework can provide all features, so it must be

extendable to let you integrate your own features.

Note that if you’re particular projects require you to work with legacy databases, you can read Chapter 10,

section 10.2 to learn about the features NHibernate gives us to work with more exotic data structures.

Let’s now dig in the methodology behind NHibernate

1.4 Object/Relational Mapping

You already have an idea of how NHibernate provides object/relational persistence. However, you may still be

unable to tell what object/relational mapping (ORM) is. We will try to answer this question now. After that, we

will discuss some non-technical reasons to use ORM.

What is ORM?

Time has proved that relational databases provide a good means of storing data, and that object-oriented

programming is a good approach to building complex applications. With object/relational mapping, it is

possible to create a translation layer that can easily transform objects into relational data and back again. As

this bridge will manipulate objects, it can provide many of the features we need (like caching, transaction,

concurrency control). All we really have to do is provide information on how to map objects to tables.

Briefly, object/relational mapping is the automated (and possibly transparent) persistence of objects in an

application to the tables in a relational database, using metadata that describes the mapping between the objects

and the database. ORM, in essence, works by transforming data from one representation to another.

Isn’t ORM a Visio plug-in?

The acronym ORM can also mean Object Role Modeling, and this term was invented before

object/relational mapping became relevant. It describes a method for information analysis, used in

database modeling, and is primarily supported by Microsoft Visio, a graphical modeling tool. Database

specialists use it as a replacement or as an addition to the more popular entity-relationship modeling.

However, if you talk to .NET developers about ORM, it’s usually in the context of object/relational

mapping.

We learnt in section 1.3.1 that there are many problems to solve when using ORM. We refer to these problems

as the paradigm mismatch. Let’s discuss, from a non-technical point of view, why we should face this

mismatch and use an ORM tool like NHibernate.

Licensed to Jason Wilden <jasonwilden@internode.on.net>

Please post comments or corrections to the Author online forum at

http://www.manning-sandbox.com/forum.jspa?forumID=295

1.4.1 Why ORM?

The overall solution for these mismatch problems can require a significant outlay of time and effort. In our

experience, the main purpose of up to 30 percent of the .NET application code written is to handle the tedious

SQL/ADO.NET and the manual bridging of the object/relational paradigm mismatch. Despite all this effort,

the end-result still doesn’t feel quite right. We have seen projects nearly sink due to the complexity and

inflexibility of their database abstraction layers.

Modeling mismatch

One of the major costs is in the area of modeling. The relational and object models must both encompass the

same business entities. However, an object-oriented purist will model these entities in a very different way

than an experienced relational data modeler. You learnt some details of this problem in section 1.3.1. The usual

solution to this problem is to bend and twist the object model until it matches the underlying relational

technology.

This can be done successfully, but only at the cost of losing some of the advantages of object orientation.

Keep in mind that relational modeling is underpinned by relational theory. Object orientation has no such

rigorous mathematical definition or body of theoretical work. There is no elegant transformation waiting to be

discovered. (Doing away with .NET and SQL and starting from scratch isn’t considered elegant.)

Productivity and maintainability

The domain modeling mismatch problem isn’t the only problem solved by ORM. A tool like NHibernate

makes you more productive. It eliminates much of the grunt work (more than you’d expect) and lets you

concentrate on the business problem. No matter which application development strategy you prefer—top-

down, starting with a domain model; or bottom-up, starting with an existing database schema—NHibernate

used together with the appropriate tools will significantly reduce development time.

Fewer lines of code makes the system more understandable since it emphasizes business logic rather than

plumbing. Most important, a system with less code is easier to refactor. NHibernate substantially improves

maintainability. Not only because it reduces the number of lines of code, but also because it provides a buffer

between the object model and the relational representation. It allows a more elegant use of object orientation

on the .NET side, and it insulates each model from minor changes to the other.

Performance

A common claim is that hand-coded persistence can always be at least as fast, and can often be faster, than

automated persistence. This is true in the same sense that it’s true that assembly code can always be at least as

fast as .NET code—in other words, it’s beside the point.

The unspoken implication of the claim is that hand-coded persistence will perform at least as well in an

actual application. But this implication will be true only if the effort required to implement at-least-as-fast

hand-coded persistence is similar to the amount of effort involved in utilizing an automated solution. The

really interesting question is, what happens when we consider time and budget constraints?

The best way to address this question is to define means to measure performance and thresholds of

acceptability. Then, you can find out if the performance cost of an ORM is unacceptable. Experience has

proved that a good ORM has a minimal impact on performance. It can even perform better than classic

ADO.NET when correctly used, due to features like caching and batching. NHibernate is based on a mature

architecture that enables you to take advantage of many performance optimizations with a minimal effort.

Licensed to Jason Wilden <jasonwilden@internode.on.net>

剩余308页未读，继续阅读

quanben

粉丝: 173
资源: 8

NHibernate实战：.NET ORM框架详解

NHibernate in Action

NHibernate In Action 學習書籍

NHibernate 实例

NHibernate In Action英文PDF：数据库持久化技术深度解析

NHibernate in Action (PDF英文正式版)

NHibernate in Action：英文版数据库持久化指南

NHibernate实战：英文PDF版

Nhibernate实战指南：英文版资源推荐

HibernateInAction

NHibernate 实战指南

最新资源