NHibernate Update Offers Preview of LINQ Provider

NHibernate 2.1.0, which went GA last week, is comparable to Hibernate 3.2.6/3.3.1 in terms of features, according to a posting on the Soureceforge site, where developers can download the new release.

"It’s a wide array of little things rather than any one big thing," said Stephen Bohlen, one of the NHibernate contributors and organizer of the New York City ALT.NET user group.

Among them, the upgrade features a decoupling of the dynamic proxy engine that was previously hard coded to only work with Castle Windsor's dynamic proxy engine, Bohlen told me. "That was changed so it was possible for adopters to swap in whatever dynamic proxy engine they want, whether that be one from Spring.NET, among others."

The new release also introduces a refactoring process that will lead to the introduction of the LINQ to NHibernate provider that will ultimately appear in a subsequent release, probably NHibernate 3.0, Bohlen said.

"A lot of the syntax parsing for how it actually takes the object model and turns it into executable SQL that gets sent to various different databases, is now configurable in the engine," Bohlen said. "So you can use the older parser if you need to for compatibility reasons but the newer parser is also available as a configuration choice so you can begin to get familiar with how that new parsing engine is going to work with LINQ to NHibernate."

That doesn’t' mean that LINQ to NHibernate is in this release, he cautioned, but it does mean a lot of the reshaping of the way the code works is able to actually support that now, he said. "So it's kind of a foundational work for what will eventually be in 3.0 for LINQ to NHibernate."

So what is the significance if LINQ to NHibernate? There are two core ways to structure queries in NHibernate and the two that are supported in the application today using HQL, the Hibernate Query Language. HQL is a text based language usually assembled using strings in the same way a developer would assemble SQL strings in any other data environment. "The advantage of HQL is its query is stated in terms of your objects rather than in terms of your database," Bohlen said.

"But it is still text based and therefore in a text based query language, meaning there's an opportunity to get the syntax wrong. In Visual Studio, there is no IntelliSense support for writing HQL queries."

The second way NHibernate developers can structure queries today is using the Criteria API, a set of operations and methods on the criteria class that enables using methods to construct queries. "The advantage of using methods of course is that it's strongly typed and you get IntelleSense support and it's much easier to construct those things," he said.

The problem with the Criteria API, he said, is it comes with a learning curve. LINQ to NHiberate will be a LINQ provider that will enable developers to use what is starting to become a familiar skill sets in terms of writing LINQ queries, whether people are using LINQ to Objects or using LINQ to SQL or LINQ to Entities or even the ADO.NET Entity Framework, he said.

"As more and more people know how to structure the queries using LINQ, once LINQ to NHibernate is constructed, that will enable someone to write queries against the NHibernate object model using standard LINQ syntax, the same standard LINQ operators that people are familiar with in today writing LINQ to SQL, LINQ to Entities or the Entity Framework. They will be able to use the right queries against the NHibernate object models. "You still won't be writing database queries in the sense that you won't say 'select from table so-and-so' but you will be saying 'select from this collection of objects where the following values are' and so on."

So that begs the question, will LINQ to NHibernate make NHibernate more appealing as an alternative to Microsoft's own offerings including the Entity Framework?

In terms of structuring queries, it will bring it into parity with the learning curve of an object relational mapper, according to Bohlen. "There's obviously a whole host of things that you have to get as a new adopter to ORM technology to get your head around, but certainly the query language supported by the object relational mapper is one of those areas," he said. "Once LINQ to NHibernate is actually fully baked, I think there will be a much greater parity there in terms of once you've mastered the LINQ query language you'd be able to apply those skills directly to NHibernate in the same way that today to a degree you are able to apply those skills directly to Entity Framework."

Many question how many enterprise developers will favor NHibernate over the Entity Framework once Visual Studio 2010 and the Entity Framework 4 ship next year. That release adds POCO support, template-based code generation and LINQ to Entities improvements, among other features.

Nevertheless Stephen Forte, director of technology at Telerik, which itself offers an ORM tool, wonders how quickly developers will use the Entity Framework, even though it is being baked into the .NET Framework 4.

"If you look at all these new features and say 'oh that sounds cool, but when do I use it, why should I move from ADO.NET or why should I move from LINQ To SQL," Forte told me. Microsoft still needs to make the case for that, something he is hopeful will happen around the PDC 2009 timeframe in November. Forte had more to say on all these ORM and data access technologies during a recent .NET Rocks interview.

Are you partial to either ORM technology, do you see using a hybrid of both, or are you sticking with ADO.NET and/or LINQ To SQL? Drop me a line and let me know what you think at [email protected].

Posted by Jeffrey Schwartz on July 29, 2009