NHibernate

What would NHibernate ICriteria look like in .net 3.5?

Brendan Kowitz — Sun, 17 Aug 2008 05:12:29 GMT

If NHibernate decided to ditch compatibility with plain old .net 2.0 and focus on 3.5 how would the ICriteria interface change? Previously I was throwing around an idea of using a simple lambda expression to resolve the property name. Well, I couldn't help but build on this a little more. The following idea is not supposed to be LINQ, that would be far more complicated and LINQ is essentially its own interface, which is not the point. The point is, if ICriteria was written today in .net 3.5, what could it look like? How could it change?

So just to recap, the original code sample looked like:

ICriteria c = session.CreateCriteria(typeof(Person));
c.Add(Restrictions.Eq(Property.GetFor(() => new Person().FirstName), "John"));

Paul later come back and suggested I try using a slightly different signature so that the "Person" object doesn't need to be instantiated for no reason, this means the we can do this:

ICriteria c = session.CreateCriteria(typeof(Person));
c.Add(Restrictions.Eq(Property.For<Person>(p => p.FirstName), "John"));

I like this a lot more. So this is the point where I started playing around and wanted to try and implement a neater way of integrating this to add Criterion. First off I tried implementing ICriteria.Add(Restrictions.Eq()) as an expression which looked like:

ICriteria c = session.CreateCriteria(typeof(Person));
c.Add(RestrictBy.Eq<Person>(p => p.FirstName == "John" ));

That is where I got up to in the previous post. So after this I started implementing some of the other functions found on the 'Restrictions' class such as:

.NotNull()
.IsNotNull()
.Not()
.Between()
.Gt() (Greater than)

Then I realized all of the above functions are able to be figured out using the syntax I already had: 'p.FirstName == "John"', so how about p.FirstName != "John", or p.ID > 0 or p.FirstName != null, you get the idea. This being the case, now there is no need for the Restrictions class at all, nearly everything can be figured out by using Add(). The other problem I wanted to solve was not having to keep passing the generic <Person> class in all the time. So I created a class which wraps ICriteria and keeps track of these few things, so now it looks like:

ICriteria c = session.CreateExpression<Person>()
     .Add(p => p.FirstName == "John")
     .Criteria;

Most of the other functions on the Restrictions class can be added the same way:

ICriteria c = session.CreateExpression<person>()
      .Add(p => p.FirstName == "John") //Restriction.Eq()
      .Add(p => p.LastName != null)    //Restriction.IsNotNull() 
      .Add(p => p.ID > 0 && p.ID < 1000) //Restriction.Between()
      .Criteria;

There are also other more complex things that the ICriteria interface does such as adding Projections and Joins. So how would the old AddAlias() function work? Like this perhaps:

ICriteria c = session.CreateExpression<Person>()
      .Alias<Address>(p => p.Addresses, "addr")
            .Add(a => a.Postcode != null)
            .AddAndReturn(a => a.Address2 == null)
      .Criteria;

Bringing it all together, here's a comparison between the old interface and the expressions version.

Current ICriteria:

ICriteria o = session.CreateCriteria(typeof(Person))
    .Add(Restrictions.Eq("FirstName", "John"))
    .CreateAlias("Addresses", "addr")
        .Add(Restrictions.IsNotNull("addr.Postcode"))
        .Add(Restrictions.IsNull("addr.Address2"))
    .AddOrder(Order.Asc("ID"));

Same query using Expressions:

ICriteria c = session.CreateExpression<Person>()
    .Add(p => p.FirstName == "John")
    .Alias<Address>(p => p.Addresses, "addr")
        .Add(a => a.Postcode != null)
        .AddAndReturn(a => a.Address2 == null)
    .OrderAsc(p => p.ID)
    .Criteria;

In conclusion, this is probably not going to revolutionize the global economy, but on some levels I think it feels a little more intuitive and a little more modern. In other respects, it's probably not much less typing then the original. Also with the up and coming linq provider, is this a waste of time? or does it complement it?

Feel free to have a poke around the source, and corresponding tests

NHibernate Type Safety using Lambda Expressions

Brendan Kowitz — Mon, 21 Jul 2008 21:38:48 GMT

I can't remember if this has been around before, I do vaguely remember seeing something like it.

However, I just wanted to apply a snippet of code I found on Paul's blog the other day to NHibernate. Of course we will definitely have type safety in queries when Linq-to-NHibernate is completed. But surely linq-to-nhibernate is not going to be the _only_ way of writing queries.

Using the original code snippet 'as is' would look something like this:

ICriteria c = session.CreateCriteria(typeof(Person));
c.Add(Restrictions.Eq(Property.GetFor(() => new Person().FirstName), "John"));

This is ok, but a little long winded, so I implemented another class called RestrictBy which can break down a simple lambda expression. So now I can use:

ICriteria c = session.CreateCriteria(typeof(Person));
c.Add(RestrictBy.Eq(() => new Person().FirstName == "John"));
c.UniqueResult();

This also means you'll get compile time errors for incompatible types such as:

Using the lambda expression we get to evaluate the _actual_ property and that property's type. If you wanted to clean this up some more, its not hard to then go and add some extension methods to ICriteria to produce:

ICriteria c = session.CreateCriteria(typeof(Person));
c.AddEq(() => new Person().FirstName == "John");
c.UniqueResult();

So that's it, a simple example at the moment, but it might be an option to look into a little more because the ICriteria interface is still NHibernate's native querying interface and still provides a lot of power, flexibility and programmatic building of queries.

Sourcecode:

RestrictBy.cs also a couple of unit tests here
Paul's Property.GetFor()

EDIT: For further reading, see the follow up post.

NHibernate Compatible Shared Hosts

Brendan Kowitz — Fri, 28 Mar 2008 13:21:04 GMT

NHibernate is a remarkable ORM, however with all the magic comes a few caveats, these being the difficulties running NHibernate apps in a shared hosting environment. I'm still convinced that it's entirely possible, so I've decided to start compiling a list of success and failures that others (and myself) have had in getting things working.

Compatible Shared Hosts

Host Name	Comment	Reference
Webhost4life	Reportedly works with "no hacks"	[ref]
DiscountAsp	I think this should work with IIS7 / Win 2008	[ref]
XHostSolutions	Simply email support and ask to have your application run as Full Trust	This is the host I use.

Shared Hosts known not to work

Host Name	Comment	Reference
Godaddy		[ref]
Crystaltech		[ref]

Untested / Unknown

Host Name	Comment	Reference
DiscountAsp

Useful References / Alternate Ideas

Lazy Loading with nHibernate Under Medium Trust

ASP.NET Databinding lazy properties

Brendan Kowitz — Tue, 18 Dec 2007 20:38:24 GMT

Every since using NHibernate, the effort required to use Many-to-many and one-to-many joins in business objects is a brainless exercise. When using a lazy loaded property on a business object, it just works, however, what happens when you try to bind this property using an ObjectDataSource hooked up to gridview or formview in asp.net...

As seen above, the GridView works out that it's out of it's depth with all the complex properties and only defines the simple text/int/boolean columns. The only alternative for the complex properties is to define your own template columns.

To display the value of a complex property you are still able to access the sub-properties using the Eval() command. So in the example below, I can use Eval() to display the name of the 'parent location' that is currently selected. To actually select the location, I can bind it the a custom user control using the Bind() method, this will pass in the entire lazy loaded 'Location' object. The user control must then pass back out a Location object when the ObjectDataSource needs to do an update.

After making this change my grid now has the lazy loaded 'Parent Location' property:

When the grid is in action, view mode:

Edit mode:

Although this is a relatively simple example, it does show how much code you don't need to write to do a one-to-many join using binding in asp.net 2.0.