NHibernate Reading Notes-Understanding the architectureⅠ

2.2 Understanding the architecture

The programming interfaces are the first thing you have to learn about NHibernate in order to use it in the persistence layer of your application. Figure 2.1 illustrates【图示说明】 the roles of the most important NHibernate interfaces in the business and persistence layers.

The NHibernate interfaces shown in figure 2.1 may be approximately classified as follows:
■ Interfaces called by applications to perform basic CRUD and querying operations (Create, Retrieve, Update, and Delete). These interfaces are the main point of dependency of application business/control logic on NHibernate. They include ISession, ITransaction, IQuery, and ICriteria.
■ Interfaces called by application infrastructure【底部构造】 code to configure NHibernate, most importantly the Configuration class.
■ Callback interfaces that allow the application to react to events occurring inside NHibernate, such as IInterceptor, ILifecycle, and IValidatable.
■ Interfaces that allow extension of NHibernate’s powerful mapping functionality, such as IUserType, ICompositeUserType, and IIdentifierGenerator. These interfaces are implemented by application infrastructure code (if necessary).
NHibernate makes use of existing .NET APIs, including ADO.NET and its ITransaction API. ADO.NET provides a rudimentary level of abstraction of functionality common to relational databases, letting NHibernate support almost any database with an ADO.NET driver.

2.2.1 The core interfaces
The five core interfaces described in this section are used in just about every NHibernate application. Using these interfaces, you can store and retrieve persistent objects and control transactions.
ISESSION INTERFACE
The ISession interface is the primary interface used by NHibernate applications. It exposes NHibernate’s methods for finding, saving, updating, and deleting objects. An instance of ISession is lightweight and is inexpensive to create and destroy. This is important because your application will need to create and destroy sessions all the time, perhaps on every ASP.NET page request. NHibernate sessions are not thread safe and should by design be used by only one thread at a time. This is discussed in further details in future chapters.
The NHibernate notion of a session is something between connection and transaction. It may be easier to think of a session as a cache or collection of loaded objects relating to a single unit of work. NHibernate can detect【察觉】 changes to the objects in this unit of work. We sometimes call the ISession a persistence manager because it’s also the interface for persistence-related operations such as storing and retrieving objects. Note that an NHibernate session has nothing to do with an ASP.NET session. When we use the word session in this book, we mean the NHibernate session. We describe the ISession interface in detail in section 4.2.
ISESSIONFACTORY INTERFACE
The application obtains ISession instances from an ISessionFactory. Compared to the ISession interface, this object is much less exciting.
The ISessionFactory certainly isn’t lightweight! It’s intended to be shared among many application threads. There is typically a single instance of ISessionFactory for the whole application—created during application initialization, for example. But if your application accesses multiple databases using NHibernate, you’ll need a SessionFactory for each database.
The SessionFactory caches generated SQL statements and other mapping metadata that NHibernate uses at runtime. It can also hold cached data that has been read in one unit of work and which may be reused in a future unit of work or session. This is possible if you configure class and collection mappings to use the second-level cache.
CONFIGURATION INTERFACE
The Configuration object is used to configure NHibernate. The application uses a Configuration instance to specify the location of mapping documents and to set NHibernate-specific properties before creating the ISessionFactory.
Even though the Configuration interface plays a relatively small part in the total scope of an NHibernate application, it’s the first object you’ll meet when you begin using NHibernate. Section 2.2 covers the issue of configuring NHibernate in some detail.
ITRANSACTION INTERFACE
The ITransaction【事务】 interface is shown in figure 2.1, next to the ISession interface. The ITransaction interface is an optional API. NHibernate applications may choose not to use this interface, instead managing transactions in their own infrastructure code. An NHibernate ITransaction abstracts application code from the underlying transaction implementation—which might be an ADO.NET transaction or any kind of manual transaction—allowing the application to control transaction boundaries via a consistent API. This helps to keep NHibernate applications portable between different kinds of execution environments and containers. We use the NHibernate ITransaction API throughout this book. Transactions and the ITransaction interface are explained in chapter 5.
IQUERY AND ICRITERIA INTERFACES
The IQuery interface gives you powerful ways to perform queries against the database while also controlling how the query is executed. It’s the basic interface used for fetching data using NHibernate. Queries are written in HQL or in your database’s native SQL dialect. An IQuery instance is lightweight and can’t be used outside the ISession that created it. It’s used to bind query parameters, limit the number of results returned by the query, and execute the query.
The ICriteria interface is similar; it lets you create and execute object-oriented criteria queries.
We describe the features of the IQuery interface in chapter 7, where you’ll learn how to use it in your applications. Now that we’ve introduced you to the main APIs needed to write real-world NHibernate applications, the next section introduces some more advanced features. After that, we dive into how NHibernate is configured and how you can set up logging to view what NHibernate is doing behind the scenes (a great way of seeing NHibernate in action, if you’ll excuse the pun!).

2.2.2 Callback interfaces
Callback interfaces allow the application to receive a notification when something interesting happens to an object—for example, when an object is loaded, saved, or deleted.  NHibernate applications don’t need to implement these callbacks, but they’re useful for implementing certain kinds of generic functionality, such as creating audit records.
The ILifecycle and IValidatable interfaces let a persistent object react to events relating to its own persistence lifecycle. The persistence lifecycle is encompassed【包含】 by an object’s CRUD operations (when it’s created, retrieved, updated, or deleted).
NOTE The original Hibernate team was heavily influenced by other ORM solutions that have similar callback interfaces. Later, they realized that having the persistent classes implement Hibernate-specific interfaces probably isn’t a good idea, because doing so pollutes our persistent classes with nonportable code. Because these interfaces are deprecated, we don’t discuss them in this book.
The IInterceptor【拦截者】 interface was introduced to let the application process callbacks without forcing the persistent classes to implement NHibernate-specific APIs. Implementations of the IInterceptor interface are passed to the persistent instances as parameters. We discuss an example in chapter 8.

2.2.3 Types
A fundamental and powerful element of the architecture is NHibernate’s notion【概念】 of a Type. An NHibernate Type object maps a .NET type to a database column type (the type may span multiple columns). All persistent properties of persistent classes, including associations, have a corresponding NHibernate type. This design makes NHibernate extremely flexible and extensible because each RDBMS has a different set of mapping to .NET types.
NHibernate includes a rich range of built-in types, covering all .NET primitives and many CLR classes, including types for System.DateTime, System.Enum, byte[], and Serializable classes.
Even better, NHibernate supports user-defined custom types. The interfaces IUser- Type, ICompositeUserType and IParameterizedType are provided to let you create your own types. You can also use IUserCollectionType to create your own collection types. You can use this feature to handle commonly used application classes such as Address, Name, and MonetaryAmount conveniently and elegantly. Custom types are considered a central feature of NHibernate, and you’re encouraged to put them to new and creative uses!
We explain NHibernate types and user-defined types in section 6.1. We now go on to list some of the lower-level interfaces. You may not need to use or understand all of them, but knowing they exist may give you extra flexibility when it comes to designing your applications.

2.2.4 Extension interfaces
Much of the functionality that NHibernate provides is configurable, allowing you to choose between certain built-in strategies. When the built-in strategies are insufficient, NHibernate will usually let you plug in your own custom implementation by implementing an interface. Extension points include the following:
■ Primary-key generation (IIdentifierGenerator interface)
■ SQL dialect support (Dialect abstract class)
■ Caching strategies (ICache and ICacheProvider interfaces)
■ ADO.NET connection management (IConnectionProvider interface)
■ Transaction management (ITransactionFactory and ITransaction interfaces)
■ ORM strategies (IClassPersister interface hierarchy)
■ Property-access strategies (IPropertyAccessor interface)
■ Proxy creation (IProxyFactory interface)
NHibernate ships with at least one implementation of each of the listed interfaces, so you don’t usually need to start from scratch if you wish to extend the built-in functionality. The source code is available for you to use as an example for your own implementation.
You should now have an awareness of the various APIs and interfaces that NHibernate provides. Luckily, you won’t need them all. For simple applications, you may need only the Configuration and ISession interfaces, as shown in the “Hello World” example. But before you can begin to use NHibernate in your applications, you must have some understanding of how NHibernate is configured. That is what we discuss next.