Learning NHibernate 4

Chapter 1. Introduction to NHibernate

In this chapter, we will go over a very brief introduction to NHibernate. This chapter is mainly aimed at absolute beginners to either NHibernate or ORMs. Therefore, we will begin with a discussion around what is an ORM and what kind of problems it solves. We will then dive into NHibernate and talk about what NHibernate offers in specific. Next, we would talk about the latest version of NHibernate and what new features are added in the latest version. While I am introducing NHibernate to you, I will also touch upon the important building blocks of NHibernate. In the end, I would try to answer the question of whether it is a bad idea to use ORM, as portrayed by some experts.

For those of you who have used or read about Entity Framework (EF), I have added a section talking about features in NHibernate that are missing in the current version of EF. This is no way tries to present a picture that NHibernate is superior that EF. Rather, this information will help you to choose the right tool for the job.

What is ORM?

ORM stands for Object Relational Mapping. It is a technique that lets you map objects to relational databases and vice versa. Here, the term "object" mostly means an instance of a class. Tools that make use of ORM techniques are also referred to as ORM, which stands for Object Relational Mapper. NHibernate is one such tool. Let's take a look at a very simple example in order to understand what exactly this technique does. Suppose that you have the following Customer class:

public class Customer
{
  public string FirstName {get; set;}
  public string LastName {get; set;}
  public string EmailAddress {get; set;}
  public int Age {get; set;}
}

Tip

Downloading the example code

You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books that you have purchased. If you have purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

Every customer will be represented by an instance of the preceding class in the memory. Every such instance will also be persisted in the database. Suppose that the following database table is used to store customer instances:

CREATE TABLE tblCustomer
(
FirstName NVARCHAR(100),
LastName NVARCHAR(100),
EmailAddress NVARCHAR(100),
Age INT
);

The preceding syntax is for the MS SQL Server database. If you are using a different RDMBS, then the syntax may differ.

Depending on which ORM you are using, you will have a way to tell your ORM that the Customer class corresponds to the tblCustomer table in your database. Similarly, you can tell that the FirstName, LastName, EmailAddress, and Age properties map to columns with the same names in the tblCustomer table. Once all of this is in place, you can just tell your ORM to save an instance of the Customer class; it will ensure that a record is inserted into the tblCustomer table with the appropriate values for all the columns.

In a nutshell, that is ORM for you. ORM will handle all your database CRUD operations for you without you having to write a single line of SQL script. However, the most important principle to understand around an ORM is that it tries to bridge the gap between the OO world and the relational world. Programs written using the object-oriented principles adhere to a set of rules and support a particular set of data types. On the other hand, most RDBMSs follow rules derived from the set theory and support a set of data types that may not all be compatible with the corresponding data type on the OO side of the world. Besides this, there are differences in how new objects are constructed, how they associate with each other, what kind of operations are permitted on them, and so on.

All these differences make working with databases difficult when viewed from the perspective of the OO program. These differences are also called impedance mismatch, a term taken from electrical engineering. Impedance gives a measure of how easily the current can flow through an electrical circuit. For two electrical circuits to work in coherence with each other when connected, their impedances should match. In the same way, for a program written in OOP to work with an RDBMS in coherence, the impedance between them has to be matched. An ORM does this job.

What is NHibernate?

Obviously, it is an ORM. If I may quote from the NHibernate website:

"NHibernate is a mature, open source object-relational mapper for the .NET framework. It's actively developed, fully featured and used in thousands of successful projects."

NHibernate is a .NET port of a very famous ORM from the Java land called Hibernate. Now, Hibernate is quite old and is used by thousands of production applications. NHibernate has not only inherited most of the good features from its Java ancestor but has also been enriched with features from .NET, such as LINQ queries. To understand how powerful it can be, let's take a very simple example. If you have the Customer class from the previous section, mapped to a database table called tblCustomer, and you want to fetch all customers between 28 and 35 years of age, then with NHibernate, you can write something as follows:

var customers  = from c in session.Query<Customer>()
  where c.Age > 28 && c.Age < 35
  select c;

This is an LINQ query written in C#. LINQ stands for Language-Integrated Query. This is a feature introduced in C# and Visual Basic that offers data query and update syntax, which is similar to SQL. LINQ works against a variety of data sources but within the constraints of the C# language; further, it works nicely with the IQueryable types. If you are not familiar with LINQ, then do not worry too much as we will cover them in the coming chapters. You must be wondering what is session.Query<Customer>()? This is an NHibernate API that we will use extensively throughout this book. For now, session.Query<Customer>() returns IQueryable<Customer>. It is this queryable type that makes writing the previous LINQ query possible.

NHibernate then processes the previous LINQ query and generates the following SQL:

SELECT a_.FirstName,
  a_.LastName,
  a_.EmailAddress,
  a_.Age
FROM tblCustomer a_
WHERE a_.Age > 28 AND a_.Age < 35

As you can see, all you wrote was a simple C# LINQ expression against a C# class. You did not have to think about what the database table name is and how to form the correct SQL query; NHibernate has handled all of that for you. NHibernate has a lot of such features that will make writing database interaction code a breeze. We are going to cover these features of NHibernate throughout this book.

NHibernate is an open source project which prospers entirely on community contributions. As with any open source project, this gives a lot of transparency to every aspect of NHibernate. You can download the source code from their GitHub repository at https://github.com/nhibernate/nhibernate-core/ and check out how things are implemented. You can raise bugs on their official JIRA board, contribute to discussions around the right fixes for the defects, development of new features, and the future roadmap. All these activities are mostly led by a few top contributors, but transparency and community inclusion are what keep NHibernate going. You can access the NHibernate JIRA board by navigating to http://nhibernate.jira.com. I will not spend too much space talking about NHibernate here. Besides the fact that the whole book covers all important aspects of NHibernate anyway, I am now going to peek into some interesting NHibernate features in the remaining sections of this chapter.

Before I move onto the next section, I would like to mention that the latest stable version of NHibernate is 4.0.3.400 as of the time of writing of this book. The latest version of NHibernate can be confirmed by visiting the NuGet page of NHibernate at https://www.nuget.org/packages/NHibernate/. The latest version is an important milestone since this a major release that has come about 3 years after the previous major release 3.0. There were several minor releases in these 3 years. All these releases have collectively added a lot of great features to version 4.0 of NHibernate. Let's take a brief tour of these features.

What is new in NHibernate 4.0?

The General Availability release of NHibernate 4.0.3.400 was released on August 17 2014. This is the latest release of NHibernate as of the time of writing of this book. This release is quite important from a lot of perspectives. This is a major release of NHibernate that has come almost after three and a half years, so it contains a lot of interesting features and bug fixes.

If you are new to the ORM land or have never used NHibernate before, then you may not find this section very interesting. But hey, why not keep reading and you might find something that strikes a chord with you:

NH 4.0 is built for .NET 4.0. This may not mean much for the users of NHibernate 4.0 as you can still use older versions of NHibernate on a project that is built on .NET 4.0. However, this is a major move for NHibernate since it now gives NHibernate developers the ability to utilize new features of .NET 4.0. An immediate consequence of this was that NHibernate 4.0 now does not depend on the Iesi.Collection library to support sets (Iesi.Collections.Generic.ISet<T>) because .NET 4.0 has native support for sets, in the form of ISet<T>, and implementations such as HashSet<T>. Back in the days when the old versions of .NET did not have support for sets, the Iesi.Collections library offered a mature set functionality. NHibernate had a dependency on this external library as NHibernate uses sets to represent collections.
Support for SQL Server 2012 has improved with the implementation of the native IIF function, query paging, and SQL Server 2012 sequences.
"Mapping by code" rids you of having to write and maintain cumbersome XML mapping files. However, the general audience was never happy with this feature as it was buggy till recent times. NHibernate 4.0 has several defects in this area fixed, thus giving Mapping by code a facelift.
We all love LINQ and we all hated the fact that NH's LINQ support never matched that of Criteria or QueryOver. There has been great community contribution in this area with over 140 issues fixed. LINQ support in NHibernate 4.0 has matched that of other query providers in a lot of respects. We will be using this feature a lot in the coming chapters of this book.

NHibernate for users of Entity Framework

If you are using or have used Entity Framework (EF), then chances are you know about NHibernate. While EF has been in business for a few years now, it is only in the last couple of years that it has got some serious attention, thanks to the performance improvements brought about in EF 6.x and the implementation of some features that are at the core of any ORM. In spite of the recent popularity of EF, a natural question to ask is why you should be taking a look at NHibernate? Well, for starters, NHibernate is probably the oldest ORM in existence. The NHibernate code base has been used in thousands of production applications over the years and is quite sturdy. However, this sounds very subjective to you, so let me give you a list of features that NHibernate has but EF does not.

NHibernate has a stable and sophisticated support for second-level cache. The caching implementation of NHibernate is supported by more than one caching provider ranging from in-memory hash tables to distributed caching solutions such as NCache.
NHibernate has native support for mapping dictionaries. Dictionary mapping comes in handy in various different situations but one interesting situation that comes to my mind is building a multi-tenant system. In a multi-tenant system, multiple tenants are served from the same instance of the application and their data is stored in a single database instance. If a particular tenant has a requirement that needs to have additional properties on some entity to handle additional data about that entity, then this additional data can be stored in a dictionary of key-value pairs. This dictionary is declared as a property on the entity. NHibernate can then map these dictionaries directly to a suitable table schema.
In situations where you need to update a large number of database records as part of batch jobs, the usual session object of NHibernate may be too slow as it tracks every change made to the entities and enforces all the database relations/constraints before the changes are saved to the database. However, the stateless sessions of NHibernate speed things up manifold at the cost of losing features such as change tracking and in-memory enforcement of database constraints. EF has some support for such a behavior through an extension method called AsNoTracking or through specific options in the DbContextConfiguration class. However, in my opinion, both of these options are not as intuitive as the stateless sessions of NHibernate.
NH, in general, supports more number of databases than EF does. EF is built, tested, and most commonly used for MS SQL Server. A lot of people also use it for Oracle, but the level of support for databases such as MySQL, Sybase ASE, PostgreSQL, and DB2 is not at par with that for the other databases. If you use one of these databases, then chances are that you will face fewer problems if you are using NHibernate.
Identity generation is one of the important features offered by an ORM. Every database table must have an identity column that uniquely identifies a particular record from the other records. We skipped this part in the introduction section for the sake of simplicity. Corresponding to the identity column in the database table, you will have a class property that holds the identity value. You can then generate a unique identity value for every new instance of this class or you can ask your ORM to generate one for you. If used wisely, identity generation can save a few database trips and improve performance. A particular identity generation strategy may not work well for all situations, so having more than one strategy always helps. NHibernate comes bundled with several identity generation strategies, while EF is still catching up.
NHibernate's support for managing concurrency is far better. Concurrency is when two sessions (usually representing two different end users connecting to the database) try to update the same database record. The last session to update the record is usually working on a stale copy of data. Data is called stale when there is a latest updated version of the data present in the database than the one that you have loaded in the memory. In such a situation, in the absence of proper checks, it is possible that the session working with stale data ends up overwriting a legitimate record with some old value. NHibernate has at least three different models of concurrency management wherein NHibernate detects updates on stale data, aborts the update, and lets the application know of the same. We are going to look at these concurrency models in one of the upcoming chapters in detail, but it is worth mentioning that EF has a limited support for concurrency and it works most effectively only when used with the MS SQL Server database.
NHibernate supports global filters. Global filters let you define dynamic SQL filters once and apply them to every database query or selectively apply them to some of the database queries. One situation where this feature comes in very handy is when you are working with a multi-tenant database. Another situation that I can think of is when you are storing the localized versions of strings in the database and you filter out the correct version by using a culture filter based on the current thread culture.
NHibernate supports four different mechanisms for querying data. While LINQ is the easiest and is supported by both NHibernate and EF, the other three, namely, HQL, Criteria, and QueryOver, are only available in NHibernate. One of the useful things that you can do with these is the tuning of the final SQL generated for your code. With these different query mechanisms, you get a better control over the final SQL generated. Most DBAs would want this ability.

Is using ORM a bad idea?

ORMs offer a frictionless development experience when working with relational databases. Still, some minds in the industry feel that using an ORM is not a good idea. Of all the reasons presented against using ORMs, the two most commonly given are as follows:

ORMs abstract away databases, and hence, the important database concepts that are essential for any developer to master usually get ignored
The use of ORMs results in a performance degradation of the application

It will be interesting to drill deeper into these reasons. It is true that ORMs abstract away databases and handle almost all database interactions for you in a transparent way. You do not need to bother yourself with a deeper understanding of how an ORM is fetching data from the database. If you master APIs offered by the ORM, you will do just good to interact with a moderately complex database through the most commonly used queries. Further, since this almost always works, you never need to figure out what the ORM is doing under the hood for you. So, you indeed miss out on learning how to work with databases. If you are using your ORM to generate a database schema, then chances are that you are missing out on important database building blocks such as keys, associations, relations, and indexes. So, there is an element of truth in the first reasoning. If you do fall into this category of developers, then this lack of database knowledge will hit you the hardest when least expected.

Talking about the performance degradation caused by ORMs, I can only say that this has an element of truth but it is very subjective. I say subjective because the word "performance" cannot stand on its own. When we talk about performance, we usually refer to a benchmark. This benchmark can be the expected performance of a system or the performance of a similar system used for the purpose of comparison. The performance argument against ORMs is usually in the context of a comparison with other ways of interacting with databases, which include, but are not limited to, the use of plain SQL with ADO.NET or the use of micro-ORMs. While micro-ORMs do offer the best performance, the situation with ADO.NET is slightly different. ADO.NET offers barebones, and you need to write most of the code around reading data from datasets/data readers and hydrating objects. Depending on your experience with building performant systems, you may be able to squeeze more performance out of ADO.NET than is offered by ORMs. However, the key phrase is "experience with building a performant system." If you do not have such experience, then it may be better to stick to an ORM as you will tend to not make the common mistakes made while working with databases.

Why ORM is a better bet?

So, why should we use an ORM then? Let's take a step back and think about our options when we do not use any ORM. In the absence of an ORM, you can either use a micro-ORM or put together your own data access layer implemented using something such as ADO.NET. Micro-ORMs take a minimalist approach towards object relational mapping. Some of them use advanced language features and conventions to automatically map classes to a database schema, while others explicitly make use of custom SQL.

Micro-ORM can be called the little brother of ORMs and is an entirely different topic, so I am not going to consider this option for the sake of this discussion. So, we are left with building our own data access layer. Now what does this mean? First and foremost, this means that you are going to spend a significant amount of time in building something that lets you interact with relational data stores. Further, you are going to do this along with numerous other fellow developers from the "No-ORM" camp. Can you imagine how many times this wheel is going to be reinvented? If you are working in an environment where everyone values "code reuse," then chances are that you would try to reuse this data access layer in more than one project, thus limiting the duplication. However, in reality, this rarely happens for two reasons. One, most of the time, we are so busy delivering our own stuff that we tend to ignore work by other teams, work that you can potentially use as is in your project. The second reason is the realization of the fact that the first team that built the original data access layer did it to tailor to their needs and it does not quite fit your own needs. So, you decide to roll your own. So, all of this leads to countless developers building the similar thing all over again for every new project that they start working on.

Next is the challenge of maintaining the quality of such a data access layer. For simple applications, you can write a complete data access layer in a single class, but such an approach usually does not work for complex applications. When requirements from a data store become complex, it becomes challenging to implement a data access layer that can cope with all the requirements. Without proper experience and knowledge of different experience patterns, you are bound to build a data access layer whose quality cannot be guaranteed.

Every data access layer follows a particular pattern to interact with the database. While some data access patterns have stood the test of time, there are others that should be avoided at any cost. Rolling out a home-grown data access layer means having knowledge of what has worked for others and what has not. It also means having a gut feeling about what will work for your project depending on how the project turns out in the future. These things are not easy to come by and people who are usually good at these things have years of experience in dealing with such problems. It is not possible to have such people onboard every time you are building a data access layer. So, chances are that things may go wrong and you would invest time in fixing things. ORMs, most notably NHibernate, have been around for years. The data access patterns implemented in NHibernate are proven to be the best. At the same time, a care has been taken to avoid designs that are considered harmful for database interactions. Being an open source project, NHibernate welcomes contributions and defect reports from the general public. So, NHibernate has become richer and more stable over time. Contributions from the general public mean that NHibernate is built by learning from the mistakes of hundreds of developers and by listening to the needs of a large community of developers around the world. Not using NHibernate or any mature, open source ORM for that matter would only mean shunting out such a huge source of common knowledge from your system and reinventing the wheel.

Non-functional features required by the data access layer

Besides the above, there are some non-functional requirements that every data access layer would need to offer sooner or later. The following is a representative list of such features:

Logging: Logging probably is one of the most important non-functional requirements. You would need to log not only the errors and exceptions but also important information such as details of the SQL query sent to the database and the data returned from the database.
Caching: Caching may sound a simple thing to implement but as your domain grows complex so do the data querying patterns. Such complex data query patterns have very different caching requirements, which are not trivial to implement.
Connection management: You might think that ADO.NET offers connection management and connection pooling. Indeed, it does. But there are more features around connection management that we need. In real-life applications, you need the ability to reuse connections across multiple queries, be able to make new connections, disconnect the existing connections at the right time, and so on.
Transaction management: As with connection management, ADO.NET does offer basic transaction management but the needs of most of the real-life software around this area can soon grow complex.
Concurrency management: Concurrent updates to the same data from multiple users may result in defects that are difficult to find out. Being able to know whether you are working on stale data or not is critical to building robust applications.
Lazy loading: Lazy loading is when you load only the part of an object that is needed at the moment. We will cover lazy loading in greater detail in the coming chapters. For now, it is worthwhile to note that lazy loading is not a simple feature to implement.
Security: Your data access layer is the primary gateway to the critical data that you store in your database. The security of this data is paramount, and hence, any data access layer needs to be secured and should be hardened against attacks such as SQL injection attacks.
Batching of queries: Some queries can be batched with other queries and executed at a later time. This improves the throughput of the SQL connection and hence improves the performance. Not all data access layers are intelligent to batch and execute queries at a later time.

It is unlikely that your home-grown data access layer will have all of these features. You might manage to build some of these features, but getting all of the features in would practically not be possible. This can mainly be driven by the fact that your main objective on the project is to deliver business functionality and not build a fully featured data access layer. Even if you do manage to put together a decent data access layer that has most of the above features, what are the odds of you having tested every edge case and fixed most defects?

On the other hand, any mature ORM would offer most of these features. Since this book is about NHibernate, I will concentrate on NHibernate here. NHibernate has all of these features built into it from the beginning. These features have not only been timely tested but have also taken shape according to the real needs of the developers. Because it is an open source project, a lot of community feedback and contribution has gone into shaping these features. So, you are guaranteed to see superior implementations of most of these features.

Given all of the preceding advantages, would I consider using an ORM a bad idea? I think not. On the contrary, I would consider using an ORM to be a good idea.

Building blocks of NHibernate

Now that we know that using an ORM is not essentially a bad idea but can actually be a very productive way of writing code that interacts with the database, let's turn our attention back to NHibernate.

NHibernate stands on three important building blocks. To understand these building blocks is essential to understand and use NHibernate effectively. We are going to explore these building blocks in detail in the coming chapters, but I would like to give you a brief introduction to these now.

Mappings

NHibernate uses mappings to find out which class maps to which database table and which property on the class maps to which column on the table. Every time your application tries to interact with the database, NHibernate refers to the mappings in order to generate the appropriate SQL to be sent to the database for execution.

There are three different ways that you can tell NHibernate about the mappings. One of the ways is based on traditional XML, whereas the other two are based on the code and provide a fluent API to express the mappings. In Chapter 3, Let's Tell NHibernate About Our Database, I will talk about these ways in enough detail. However, mappings that we will use in the other chapters will only be explained using a code-based API, also called mapping by code.

I have simplified mappings for the sake of introduction, but mappings offer a lot of advanced features that go beyond the basics such as mapping tables and columns. These advanced features impact the generation of SQL, performance of the application, and resilience of the data access layer. Hence, it is important to understand and master the mappings in order to use NHibernate most effectively.

Configuration

NHibernate lets you specify via configuration a lot of details that it uses at runtime. These details affect what NHibernate does and how NHibernate does a particular thing. Although configuration is a small thing, it is important to master it. On most projects, you will deal with configuration in the initial phase, and once everything is settled, you will rarely come back to it. The only times that you will come back to it are when you need to turn on or off something and knowing how to do this will save you some time. The NHibernate configuration lets you control the following:

which database you want to connect to (MS SQL Server, Oracle, and so on)
where is that database (read connection strings)
which SQL driver to use (or which SQL client library should NHibernate use)
where are the class mappings
should NHibernate log important information
should NHibernate cache entities by default
how should NHibernate manage sessions
should NHibernate use second-level cache
where is the second-level cache

As you can see, there are some useful configuration options there. We will see the details of these options and how to configure them in Chapter 4, NHibernate Warmup.

Configuration is not just about providing the defaults for a few NHibernate settings. Configuration can be loaded in the memory, and you can do some amazing things with it. One of such commonly done things is the use of the configuration to generate database scripts. Once you define your mappings and build your configuration, you can generate a SQL script to build all database schemas, tables, relations, constraints, indexes and so on. We are going to cover this in detail in Chapter 4, NHibernate Warmup. For now, it is worth noting how important and powerful the NHibernate configuration is.

Session

Session is the most commonly used object from NHibernate. Any database interaction that your application needs to do using NHibernate, it must do so by using a Session object. Think of a Session object as a wrapper around the pipe to the database, which is an SQL connection. The Session object not only manages the connection to the database but also exposes methods (some directly and the others indirectly through extension methods) that let you write code to interact with the database in the form of queries and create, update, and delete operations. The Session object also exposes the API for transaction management. Further, the Session object implements a form of caching that boosts the performance of queries. This list can go on as there are so many features that the Session object offers. However, let's leave those features to later chapters where we will look at them in detail.

Because of the rich set of features that the Session object offers, the Session object is the most commonly used NHibernate type. Since Session is so commonly used, NHibernate has implemented it in such a way that creating a new Session object is a very cheap operation. However, this does not mean that you should freely create new instances of the Session object. There is some penalty that you will have to pay directly or indirectly when you create a large number of session objects randomly. There are some rules that if you play with, you can gain all the benefits of cheap Session objects. We will cover all of these rules at appropriate times in different chapters of this book.

Filter reviews by

All

Amazon verified reviews

M. Kvist Oct 12, 2015

I had been using NHibernate for over a year before reading this book. Yet in every chapter I found something very useful that I didn't know.You are taught configuration by XML which is awkward, but it's an effective way of learning all the configuration options. You are however encouraged to use Fluent NHibernate for the mappings, which is a modern and popular method for mapping by code.Older constructs such as HQL, Criteria API and to some extent, QueryOver are just lightly touched upon, and the book instead promotes the modern LINQ method.One of the most rewaring chapters for me was how to use NHibernate in a real life application, which the author does really cleanly as he introduces the onion architecture and builds on IoC. You are also shown how to concretely build a repository and extend it using Specification pattern and Query object pattern.I came out of this wondering how to combine eager fetching with the Query object pattern, which seems like a reasonable extension in real life projects. I would have liked to read more about that in the book.I thoroughly enjoyed this book and would recommend it any time.

Amazon Verified review

Leonhard Sep 05, 2016

Fand das Buch sehr gut strukturiert und gelungen aufgebaut. Ohne jedgliche Vorkenntnisse zu den Eigenheiten von NHibernate gibt es einen guten, praxistauglichen Einblick. Neben der Konfiguration, den unterschiedlichen Möglichkeiten der Abfragen wird u.a. auch behandelt wie spezielle Wünsche wie Lazy Loading oder Updates mit/ohne Locks konfiguriert werden können.Zusammengefasst:Für mich als Einstieg in eine neue Welt trotz Hintergrundwissen über andere O/R Mapper vieles neues gelernt. Klare Kaufempfehlung - auch für erfahrene Entwickler geeignet

Amazon Customer Dec 03, 2017

I must have in your bookshelf

Samir Aguiar Jan 06, 2016

I have just finished this book and I'm glad I bought it. This is the NHibernate book I was looking for.I decided to learn more about NH because I'm using it at my current job and I was tired of asking for help when something complex was needed. But although I was not a beginner, I was not an expert either so the official documentation never helped me much. This book though is an in-depth tutorial, a guide, that you can easily follow along from the beginning to the very end while understanding every piece of it.Chatekar's writing is clear and straightforward. It's detailed enough to give you an understanding of the topic and summarized enough so you don't get tired. The first half of the book is more about teaching you the basics: there's a simple problem and the author slowly builds a solution that uses NHibernate. The examples are easy to follow and the chapters are divided so that NHibernate configuration, entities mapping and database querying/writing are all covered separately. The second half of the book advances into more complex topics such as project organization (software architecture), NHibernate usage on web projects, design patterns, dependency injection, performance (caching, lazy loading, future queries) and so on. Also, along the road the author gives a handful of valuable advice about best practices and common pitfalls/caveats so that in the end you are not just a person with a new complex skill and no idea of where to begin to apply it.The only two things that prevented me from giving it 5 stars were the lack of a code revision and more explanation of entities mappings.In the first half, the author goes into implementing a solution to the problem proposed. If you try to follow along, you won't be able to either compile or run the code as there are a lot of tweaks required. I've only managed to run it after changing NHibernate's configuration and checking the book source (which also didn't compile). The book webpage could at least contain some errata or guidance for that (I did submit some to Packt but it never got published).Secondly, I still think that there could have been more discussion about mappings and relationships, which are the heart of NHibernate and the source of many Stack Overflow questions. Again, the documentation is not very helpful here. For instance, the author made all relationships bidirectional and never got much into unidirectional relationships. Why one-to-one relationships cannot be unidirectional? What about mapping an FK Id into its own property to avoid loading an associated entity and mimic ISession.Load() behavior? What about nested relationships with relationships between children? Those are a few questions that remained after reading (and which of course I'll be exploring myself) but could have been clarified in the first chapters.Anyway, despite the above critics the book is definitely worth it and will help anyone to overcome the initial learning curve of NHibernate. It's not meant to cover all the features but rather just kick start the reader -- which it has successfully accomplished.

julian Nov 12, 2018

Very good book! 100% recomended, clear and complete, the content is very well explained. I dont rate 5 stars because i think that there are 2 subjects missing:1) Many to many relationships with additional parameters2) Logging

Learning NHibernate 4: Explore the full potential of NHibernate to build robust data access code

What do you get with Print?

Learning NHibernate 4

Chapter 1. Introduction to NHibernate

What is ORM?

Tip

What is NHibernate?

What is new in NHibernate 4.0?

NHibernate for users of Entity Framework

Is using ORM a bad idea?

Why ORM is a better bet?

Non-functional features required by the data access layer

Building blocks of NHibernate

Mappings

Configuration

Session

Summary

Page 1 of 8

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Product Details

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

Filter reviews by

People who bought this also bought

About the author

FAQs

Learning NHibernate 4: Explore the full potential of NHibernate to build robust data access code

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Product Details

Packt Subscriptions

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

Filter reviews by

People who bought this also bought

About the author

FAQs