BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Introducing NHibernate 3.0

Introducing NHibernate 3.0

This item in japanese

Bookmarks

NHibernate 3.0 is the first major release of the popular ORM in over a year. With the release it has changed the CLR version to .NET 3.5. This allows the creation of the QueryOver API, while replaces the string-based ICriteria expressions with strongly typed lambda expressions. This is in addition to the built-in LINQ provider.

There are a number of breaking changes in this release. One change is improved support for nullable types. In previous versions “when using a <map> with an <element> that is a nullable type (DateTime? for example), you can't insert or update records with a null value.” Instead of silently ignoring the null value like past versions, NHibernate 3.0 will now correctly update the database. A couple of function signatures have changed and the methods marked as obsolete in previous versions have been removed.

In related news, Patrick Smacchia of NDepend is offering a code analysis report on NHibernate using said tool. Patrick’s opinion of what that analysis means can be found on the NHibernate blog. He summarizes it as:

For a brief summary, NH is ok on:

  • The too many assemblies problem (my god, 95% of professional projects I can see have hundreds of asm, without any valid reason except to dramatically slow down everything on the developers workstation and build machines!!!)
  • Not enough code coverage, NH has a healthy global 76% code coverage ratio. I mean, just NH handcrafted and generated code, not counting test code. Btw, around 18K LoC are generated on a total of 63K LoC.
  • API breaking change, the team is pretty careful with the NH public surface and this attention is made obvious by comparing NH V3.0.0 with the previous NH v2.1.2 version.
  • Dead code

I found room for improvement in:

  • Code contract usage, NH doesn't use any code contracts Fx (nor MS Code Contract API nor Debug.Assert(...)).
  • Despite the global great 76% code coverage ratio, many methods or types are 90%+ covered by tests instead of 100%. The problem is that often, subtle bugs hide in the remaining few percents hard to test and not covered code.
  • A better global code architecture (this is not feasible since NH public API cannot be refactored for obvious reasons)
  • A respect for basic code metrics quality thresholds (too complex methods, god classes, fat code, methods with too many parameters etc...).

Rate this Article

Adoption
Style

BT