Thank you to the awesome team at Packt Publishing and my amazing technical reviewers, Fabio Maulo, Jose Romaniello, Tuna Toksoz, and Gabriel Schenker, for all the support and guidance. We made a great book!

Overview of NHibernate 3.0 Cookbook

• Master the full range of NHibernate features
• Reduce hours of application development time and get better application architecture and performance
• Create, maintain, and update your database structure automatically with the help of NHibernate
• Written and tested for NHibernate 3.0 with input from the development team distilled in to easily accessible concepts and examples
• Part of Packt’s Cookbook series: each recipe is a carefully organized sequence of instructions to complete the task as efficiently as possible

The NHibernate Cookbook explains each feature of NHibernate 3.0 in detail through example recipes that you can quickly apply to your applications. Set yourself free from stored procedures and inline SQL. Quite simply, if you build .NET applications that use databases, this book is for you.

The book will take you from the absolute basics of NHibernate through its most advanced features and beyond, showing you how to take full advantage of each concept to quickly create amazing database applications. Beginners will learn several techniques for each of the 4 core NHibernate tasks – mapping, configuration, session & transaction management, and querying – and which techniques fit best with various types of applications. In short, you will be able to build an application using NHibernate. Intermediate level readers will learn how to best implement enterprise application architecture patterns using NHibernate, leading to clean, easy-to-understand code, and increased productivity. In addition to new v3.0 features, advanced readers will learn creative ways to extend NHibernate core, as well as techniques using the NHibernate search, shards, spatial, and validation projects.

Get solutions to common NHibernate problems to develop high-quality performance-critical data access applications

What you will learn from this book :

• Create a persistent object model for moving data in and out of your database
• Build the database from your model automatically
• Configure NHibernate for use with WebForms, MVC, WPF, and WinForms applications
• Create database queries using a variety of methods, including the new LINQ to NHibernate and QueryOver APIs
• Build an enterprise-level data access layer
• Improve the performance of your applications using a variety of techniques
• Build an infrastructure for fast, easy test-driven development of your data access layer
• Extend NHibernate to add data encryption and auditing
• Implement entity validation, full-text search, horizontal partitioning (sharding), and spatial queries using NHibernate Contrib projects

Approach

This book contains quick-paced self-explanatory recipes organized in progressive skill levels and functional areas. Each recipe contains step-by-step instructions about everything necessary to execute a particular task. The book is designed so that you can read it from start to end or just open up any chapter and start following the recipes. In short this book is meant to be the ultimate "how-to" reference for NHibernate 3.0, covering every major feature of NHibernate for all experience levels.

Who this book is written for

This book is written for NHibernate users at all levels of experience. Examples are written in C# and XML. Some basic knowledge of SQL is assumed.

We talk about where to get NHibernate, a quick overview of starting an NH app, the state of NHForge, tooling and commercial support, the NHibernate ecosystem, and we compare the new EF “unicorn” features to features in NHibernate.

So, go listen now.

Thank you Scott, Fabio, and the guys at Pwop! I think the show turned out great, despite my nerves.

Oh, yeah. Frist!!!!!1!!!!one!!

It is an error to use a section registered as allowDefinition=’MachineToApplication’ beyond application level

It’s mysterious because I didn’t change my .configs. Double-clicking on the error took me to the <authentication> section of the web.config at the root of my app. It’s legal to define it there. Strange.

After trying a few different things, I started commenting out larger and larger chunks of my config, until it looked like this:

<configuration><!-- ... --></configuration>

Clearly, the error message was wrong.

As it turns out, this was my first time to build the app after using VS 2010’s Publish feature to throw it up on a server for a demo & user testing. Publishing packages up the website under .\obj\Release\Package, and it doesn’t clean up after itself. The next time I built my application, the compiler barked because I had a web.config hidden a few layers deep under .\obj with an <authentication> element.

I discovered the issue when I compiled my app at the command line and saw the full path on the error message. So, kill the .\obj folder after each publish, and you’ll never have this trouble.

Well, Simon Duduica is porting this over to .NET and NHibernate, and he’s making some AMAZING progress. On June 28th, he shared this news with us on the NH Contrib development group:

Hi everybody,

I have news regarding Envers.NET. I’ve commited a version that works in basic tests for CUD operations, with entities that have relationships between them, also with entities that are not audited. To make things work I had to make two small modifications of NHibernate, both modifications were tested running all NHibernate unit tests and they all passed. I already sent the first modification to Fabio and the second I will send this evening. I would like to thank Tuna for helping me out with good advices when I was stuck

So, on to the topic of this post. For NHibernate 3.0 Cookbook, I’ve included a section that explains how to use NHibernate to generate audit triggers. Originally, I had planned to use the code from my previous blog post on the topic, but I didn’t like its structure. I also didn’t want to include all that plumbing code in the printed book. Instead, I’ve rewritten and contributed the “framework” code to uNHAddIns. The “how-to use it” is explained in the book, so I won’t explain it here.

Today, I was writing an integration test for this contribution, and thought the idea was worth sharing. I have a simple Cat class:

When I do anything to this cat, in addition to the normal INSERT, UPDATE, or DELETE, a database trigger records that action in a table called CatAudit:

I wanted an easy way to investigate the contents of this table to prove that my audit triggers worked. Here’s what I came up with, along with help from Jose Romaniello (@jfroma). First, I created a class to match this table:

Next, I mapped it, made it readonly and excluded it from hbm2ddl with this mapping:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
				   assembly="uNhAddIns.Test"
				   namespace="uNhAddIns.Test.Audit.TriggerGenerator">
  <typedef class="NHibernate.Type.EnumStringType`1[[uNhAddIns.Audit.TriggerGenerator.TriggerActions, uNhAddIns]], NHibernate"
           name="triggerActions" />
  <class name="CatAudit"
         mutable="false"
         schema-action="none">
    <composite-id>
      <key-property name="Id" />
      <key-property name="AuditUser" />
      <key-property name="AuditTimestamp" />
    </composite-id>
    <property name="Color"/>
    <property name="AuditOperation" type="triggerActions" />
  </class>

</hibernate-mapping>

I made it readonly by setting mutable="false" and excluded it from hbm2ddl with schema-action="none". That’s it!

By the way, the <typedef> along with type="triggerActions" just tells NHibernate I’ve stored my TriggerActions enum values as strings, not numbers.

NHibernate 2 Beginner’s Guide by Aaron Cure is the 3rd published book about NHibernate. Each example in this book is presented in both C# and VB.NET, and some knowledge of these languages, as well as some basic understanding of ASP.NET WebForms is assumed.

Overall, for OR/M beginners and Entity Framework refugees, it provides a good foundation of NHibernate knowledge. The examples are simple enough to understand, and can easily be applied to real-world scenarios. There are, however, a few points of concern, such as the database-first approach, and the prescription of code generation.

Here’s a quick summary of what’s covered in each chapter:

As you might expect, chapter 1 gives a general overview of NHibernate, along with some code listings.

Chapter 2 sets up the database and table structure for the example model.

In chapter 3, the author takes us in to the world of POCO model design. He shows us NHibernate data types and their corresponding .NET data types, as well as setting up a collection for a one-to-many relationship.

In chapter 4, we begin the mapping process. After just a few pages, we have a completed NHibernate xml mapping. The chapter ends with a nice, quick example of a Fluent NHibernate code mapping. Chapter 4 is available for preview on the Packt Website.

In chapter 5, we start to get in to true NHibernate territory. The author shows us how to build a session factory, open a session, and then explains the proper use of transactions (Yes!). I would have preferred an example of session-per-request over the session provider singleton. Folks, save a kitten. Don’t use singletons.

Chapter 6 shows off all the log4net goodness baked in to NHibernate.

Chapter 7 explains the ins and outs of NHibernate configuration, with code and xml examples.

Chapter 8 shows us an example Data Access Object and how to build some Criteria queries with projections, paging, and sorting, It’s good stuff for beginners, but it doesn’t cover HQL.

In Chapter 9, the author shows us how to use NHibernate with ASP.NET WebForms data binding. No beginner’s book would be complete without showing the Microsoft way.

Chapter 10 deals with ASP.NET security and authorization, including a membership provider based on NHibernate.

Chapter 11 shows off several code generation tools. While this is the logical destination for anyone using a database-first approach, with a model-first approach, its unnecessary for all but the largest projects.

Disclosure: In exchange for non-monetary compensation, I worked as one of two technical reviewers on this book, and I am currently writing NHibernate 3 Cookbook, to be published by Packt later this year.

Simon Duduica of Bucharest, Romania and his team are porting Hibernate Envers to .NET / NHibernate.

Michele Minorello is working on NHibernate Search to add Loquacious configuration and Linq2Lucene.

I have a book deal with Packt Publishing. NHibernate 3.0 Cookbook will cover existing and new 3.0 features of NHibernate, as a series of short, easy to follow recipes that can be combined to build great NHibernate applications. In addition to NHibernate 3, the book also covers NHContrib projects, some ideas from uNHAddIns, fluent & auto-mapping with Fluent NHibernate, and ConfORM.

I’d like to send a HUGE thank you to my technical reviewers, including Fabio Maulo, Jose Romaniello, and Tuna Toksoz.

When creating lambdas (including LINQ expressions) inside a for each loop, don’t use the iterator variable in your lambda. Let me explain with some code:

foreach (Type controllerType in controllerTypes)
{
     kernel.Bind(controllerType).ToSelf().InRequestScope();
     kernel.Bind<IController>().ToMethod(ctx => ctx.kernel.Get(controllerType)).Named(GetName(controllerType));
}

Why am I using a method to get the controller? It just so happens that my AccountController is also a domain event handler for my AccountNameAlreadyUsed event. This goes back to Ayende’s tip in my domain events post: To get a message back to the UI, fire a new event and have the UI listen for it. In this case, I need the UI to complain when the account name they selected is already being used.

In case your mind has wandered to the dark side, throwing exceptions is not an acceptable way of passing messages in an application.

Now, why the odd mappings? Let’s say I bind IController and IHandle<AccountNameAlreadyUsed> to AccountController in the request scope. It doesn’t quite work like you would first expect. You will have one instance of AccountController returned for IController and a separate instance for IHandle<AccountNameAlreadyUsed>.

Instead, I’m saying that for each request for an IController, go get an AccountController, essentially delegating the request to the ToSelf() binding. I have a similar ToMethod() lambda binding for IHandle<AccountNameAlreadyUsed>. Since both interface bindings are fulfilled by the ToSelf binding, only one instance of AccountController is created for the request, instead of two.

So, this explains why I need the lambda in the first place. Why didn’t the code above work?

As it turns out, there was some funny business going on underneath the covers between the foreach iterator and the lambda. Here’s the symptom: No matter which “instance” of the lambda was being referenced, inside the lambda, the iterator variable (controllerType) was always the first value that was iterated. No matter which controller I requested, I always got an instance of AccountController, since it happens to be first alphabetically.

Once you realize what’s going on, the fix is simple. Create another variable and use it inside the lambda instead. So, instead of the code above, we get this:

foreach (Type controllerType in controllerTypes)
{
     var controllerType2 = controllerType;
     kernel.Bind(controllerType).ToSelf().InRequestScope();
     kernel.Bind<IController>().ToMethod(ctx => ctx.kernel.Get(controllerType2)).Named(GetName(controllerType));
}

If, instead of a lambda, we had a LINQ expression, the compiler would generate a warning about this issue – at least in VB.NET. If I hadn’t already seen that warning from LINQ expressions, I would probably still be bug hunting.

Jason

• Fabio has been busy on some really amazing mapping magic.
• Aaron Cure’s NHibernate 2.x Beginners Guide from Packt Publishing will be out in May.
• I’m making progress on Project Nenverse. The concept is similar to Hibernate’s Envers. I’m not ready to announce it to the world just yet, but you want to look over the code or even contribute, it’s out there.
• In an effort to avoid meta-blogging at all cost, I won’t mention the cool new stuff over on the right, or the new text up above.

That’s it for now.

The ALT.NET crowd is almost exclusively C#, except where they’ve moved beyond it.  If I’m going to participate, it’s past time for me to become fluent. Until at least April, I won’t write a single line of VB.NET outside of work.