Ayende Rahien, a contributor to NHibernate along with many other open source projects, has written up a post listing the features he likes about the ORM tool.

I am a fan of ORM and have used NHibernate extensively on a large project over the last few years. Prior to that, I had used TopLink and Hibernate on java projects.

Ayende’s listing pretty much summarizes why I like NHibernate and also has points that apply to many other ORM products as well:

Caching. NHibernate is specifically flexible in this area but many ORM products excel in this area over sql based DAL implementations.

Multi-database support. Using an ORM insulates your code from the differences in database dialects. This might sound insignificant, but if you have ever had to migrate any application from Oracle to SQLServer, for instance, you will know what a chore it can be.

A dramatic reduction in plumbing code for your application. Although he does not directly say this in his list, he does mention writing applications with no sql in them. What I’ve noticed is that there is a ton of code that gets written in your application just to put data in your domain model and pull it back out. Using an ORM removes this code from your application and puts in the domain of the ORM, which is code someone else writes and tests.

Using an ORM seems to encounter a great deal of resistance from some enterprise developers. Below are a few of the reasons that are usually given against using an ORM product on a project:

Even though you are not writing sql, you still have to perform the mapping.

The sql generated by the ORM cannot be optimized for specific cases and will be slower.

Using reflection is slow.

Using an ORM makes the data access problems more difficult to debug.

Everyone knows sql and nobody knows <ORM product>.

Even though are not writing sql, you still have to perform the mapping

This is a good point. It is true that the work of mapping data to columns in a database is moved from sql to the mapping layer of the ORM. In the case of NHibernate, this would be XML files. So in that instance, no work or time is saved. Where the time savings comes in to the picture is when the actual mappings are used. NHibernate takes those mapping files and performs the domain object instantiation and population for you.

Detractors of the ORM approach might counter with the argument that the usage of the ADO.net data constructs, for instance the typed dataset, also removes the need to write object population code. Although this might be true, I believe that passing ADO.net data types around your application leads to poor application architecture, not to mention performance problems. Typed datasets are notoriously slow when it comes to serialization.

The sql generated by the ORM cannot be optimized for specific cases and will be slower

This might be true for certain ORM products, but has not been my experience with NHibernate. The generated sql is quite good. However, I have encountered situations where the sql has been unacceptably slow and in those cases I can almost always place the blame on a poorly designed database model.

NHibernate has the ability to pass sql to the database, if needed. SQL optimizations can also be placed in the mapping files to help in situations where NHibernate could not generate the optimal queries. Named Query support, added to NHibernate 1.2, has helped as well for specific query situations that might not be the normal path for searching for a given object type.

Using reflection is slow

This is always an interesting discussion to have with a stubborn developer. Yes, it is true that a method invocation via reflection would be slower than a method invocation compiled into the IL directly. The tradeoff you are making is flexibility for a little speed. The reality of the situation is that the slowdown for reflection will be dwarfed by the IO wait for the database and you will not notice it.

NHibernate also has functionality called the reflection optimizer which will dynamically generate classes for populating your domain objects at startup time. This a tradeoff in startup time to remove the cost of reflection for each domain object population. Early versions of the reflection optimizer were noticeably slower at startup for larger numbers of mapped classes, but this has been corrected in the newer versions of NHibernate.

Performance problems in enterprise applications are caused by poor database design or poor approaches to data retrieval in 99% of cases. I should also lump screens that have too much data on them in with this category as well. The other 1% of the time the performance problems are caused by poorly written threaded code, poor algorithms, and poor integration choices with 3rd party applications. I have never encountered an enterprise application that was too slow because of reflection usage.

Using an ORM makes the data access problems more difficult to debug

I hear this complaint a lot at the beginning of projects specifically from developers that have never used ORM before. I would say that the real statement that should be made about the subject is:

Using an ORM makes the data access problems different to debug.

Most of time, a developer simply needs to familiarize themselves with the debugging facilities available in the ORM tool they are using. There is cost to learning what is available, just as there is a cost up front for learning any new tool or concept, but the productivity that ORM gives a project overall will make up for the learning curve.

Everyone knows sql and nobody knows <ORM product>

I also hear this complaint a lot at the beginning of project where I propose using ORM. It is difficult to convince someone that ORM will payoff after the learning curve is overcome when they have never used an ORM product. There are many blog posts on the web complaining that ORM does not pay off in the long run but this simply has not been my experience.

The response I usually give is to try the product for a pilot or proof of concept to test the pluses and minuses. Most clients are won over when they see the benefits of caching in the ORM and the ability to migrate databases with just minor mapping file changes (or maybe none). Also, when they actually try using NHibernate or another ORM product, they find that the product is not quite as unapproachable from a technical standpoint as they thought when they first heard of the concept.

One of the nice features that will be available this time around is full source code and permission to compile it if you need to fix a bug.

Release Notes are available here. I was pleased to see a few of the items that I had complained about corrected in this release.

IControllerFactory.CreateController() now takes a string for the controller name instead of a Type instance. This helps a lot for IOC containers because most people seem to prefer names instead of types.

Added Dispose method to IControllerFactory to support IOC recycling semantics

and most important: ControllerBuilder.SetDefaultControllerFactory has been renamed to SetControllerFactory and now has an override that takes and instance of IControllerFactory.

The last one is nice because I had to write some ugly code before in SpringControllerFactory (MVCContrib) because SetDefaultControllerFactory had previously taken a Type parameter for the IControllerFactory. If you wanted to share a spring.net context between the controller factory instance and another part of your app you had to resort to the ugly code method because you had no control over when and how often the controller factory was created.

Thanks should go to the ASP.NET MVC development team for obviously taking feedback from the community seriously. Check the release notes for other improvements to the api.

Not only are http protocols like SOAP and RSS supported but socket based networking is also included. This could mean that Silverlight applications have the ability to communicate with applications on the host computer via remoting. I’ll be checking that out when the beta comes.

Threading will be there.

Local storage. This will be big for Silverlight, in my opinion.

I think the crucial component affecting adoption by developers will be how much of WPF is available. Scott mentioned that it will be a compatible subset. If this subset is large enough that component vendors are able to deliver controls that work the same on standalone clients and in Silverlight, the adoption will be swift and wide.

Phil Haack, who is working on the ASP.NET MVC project at Microsoft, posted an explanation of the choice they made to change the abstraction of HTTPContext from an interface to an abstract base class.

This topic is something I like to ask about in interviews for more senior developers who are expected to take on design work as well as development. The answer I generally look for is something along the lines of:

Abstract base classes should be used in cases where the actual behavior is significant to the contract.

Phil goes in to much more depth here and discusses something that is also very important: the choice between interfaces and abstract base classes is a crucial component to flexibility when it comes to versioning.

Read Phil’s post on this. It is a good explanation of the tradeoffs involved.

I just read this post on InfoQ written by Jay Flowers. Jay discusses a new framework that has been released on CodePlex called White.

White is a testing framework for the UI layer and supports Win32, Windows Forms, WPF, and the SWT java framework. For those of you who may be surprised about the java framework part of SWT, I’ll let you know that this is possible because SWT is actually implemented using native UI Widgets on each platform it supports. Since native code is being executed, I would presume any testing framework that works at the Win32 level would also work on SWT.

The thing I really like when I first look at White is the syntax and the apparent support of non standard UI controls. The main drawback I have seen with other attempts at UI testing frameworks is that they do not easily accept controls that are not shipped with Windows Forms.

The CodePlex site has some samples and a link to a good getting started tutorial.

JetBrains has announced the EAP for ReSharper 4.0. The product supports most of the C# 3.0 features, but sadly still no LINQ support. They have added quite a bit to ReSharper, in addition to the new language features. I am looking forward to the final release.

Microsoft Patterns and Practices has released a CTP (Community Technology Preview) of Unity, a new DI container. So far, documentation is lacking but hopefully will be forthcoming. It appears future versions of Enterprise Library will utilize this container. P&P is having a workshop next week for those who really want to jump in head first.

For those who might be a little confused by this offering because of the previous pushing of ObjectBuilder from the P&P team, here is a post going into some detail about ObjectBuilder whether or not is does DI.

Update 2/15/2008 10am –

Grigori Melnik, from P&P, kindly pointed out that a CHM is shipped with Unity. After checking, I found that I missed it because the zip file places the CHM one directory above the Unity directory in the tree. Since everything else in the distribution started from the Unity directory, I overlooked it.

I am still having some problems reading the CHM file from my machine. The help browser seems to be attempting to read the content from the internet and cannot find it. Since people are referring to the documentation in discussion posts, this must be something specific to my machine or a low percentage problem.

Update 2/15/2008 11:20am –

The problem with the viewing of the CHM was security related. The short answer is open the file properties dialog for the CHM file, uncheck Read-only, press the Unblock button and accept the changes. The longer description is here.

I forgot to include this in my post yesterday but John Robbins, from Wintellect, has announced version 1.1 of.Net Mass Downloader. This handy tool allows you to download all available source code for the .Net framework, all at once.

VS.net 2008 will download the code once it is configured, but only a little at a time. For those who want to peruse the code at their leisure, this would not be acceptable.

StickyNotes is a VS 2008 package that adds notes to solutions, projects, and project items. The information is stored in the solution and project files. This is functionality that I have always thought would be nice to have in Visual Studio. The coolest part of this is that the tool window is not WinForms, it is WPF. Written by Pablo Galiano and hosted on MSDN Code Gallery. Sadly, no source code is available yet but it is promised soon.

MSDN Code Gallery is a new site that was introduced by Microsoft. The site already has many good examples and pointers to good information. It looks strikingly similar to CodePlex, only not so green. I am not sure why these sites needed to be separate but I am sure someone has a good reason.

Scott Hanselman has put up a post with various VS themes. It has become very fashionable to show off your custom themes lately. I sort of like the Jedi Scheme. The name is certainly a can’t miss.