Introducing NHibernate 3.0

Posted by Jonathan Allen on Dec 12, 2010

Sections

Operations & Infrastructure,

Architecture & Design,

Development

Topics

.NET ,

Data Access ,

Programming ,

nHibernate ,

Database

Share |

RELATED Research

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...).

RelatedVendorContent

Want to know how software releases can be stress-free and happen with one click? Try Go free!

Improving Software Delivery Cycles: Pre-requisites and Inhibitors

Automating Error Reporting for .NET Applications

Troubleshoot Java/.NET performance while getting full visibility in production

RDBMS to NoSQL: Managing the Transition

Related Sponsor

Go: Agile Release Management Solutions. Go enables predictable, defect-free and timely software releases.

1. Back to top

   What's wrong with more assemblys?

   by monser corp

   I don't know since when too many assemblys/projects becomes a sin - it's a good way to control dependencys. Face it, there are way too many primary programmers than qualified ones, and by using different assemblys you can force some dependecy rules.
   For projects like NH, it might make sense that after build, there is a merge process to merge them to one, but I really don't think just namespace is good enough to control this.

   Reply

2. Back to top

   Re: What's wrong with more assemblys?

   by Jonathan Allen

   I personally have a black and white view on this matter. If you can bundle everything into a single EXE, awesome. If not, you need an installer anyways and all those extra assemblies just make partial builds faster.
   
   But to be fair, Patrick Smacchia probably has a heck of a lot more experience analyzing .NET projects than I do.

   Reply

3. Back to top

   Re: What's wrong with more assemblys?

   by Patrick Smacchia

   monser corp please don't foster what I consider the most harmful anti-pattern in the .NET real-world of development.
   There are tools to check dependencies, NDepend of course, but also VS 2010 Ultimate and certainly some others tools.
   
   I literally have seen dozens of projects rooted just because they had hundreds of VS projects and assemblies. Treat assemblies for what they are: a physical mean to package code. Checking dependencies with assemblies, is treating them as a logical means.
   
   Jonathan pinpointed a great advantage of having just one assembly: deployment is made easier. But there are two even better advantages of keeping the number of assemblies small:
   - physical organization of the code sources is made much easier
   - compilation time is decreased dramatically, it can be in order of magnitude.
   
   Dear reader, I confirm, by having few assemblies, your big project you are working can be compiled in just a few seconds on your workstation instead of several minutes!
   
   I have written a post on this, and plan to polish it into a white book:
   codebetter.com/patricksmacchia/2008/12/08/advic...

   Reply

4. Back to top

   Re: What's wrong with more assemblys?

   by Mark N

   The slow compilation issue sounds like a platform issue. If this forces you to use a "poor" architecture, then you are using the wrong platform.
   
   From my experience, having more "assemblies" actually forces better code organization. It is much easier to combine code than it is to break it apart. It makes you have cleaner APIs. If you can combine multiple Projects into a single assembly (I don't know and have not tried) then that will solve some of the issues, but might cause others.
   
   Code should be organized based on reasons _other_ than what you listed. If only one assembly is needed, then only create one.

   Reply

5. Back to top

   Re: What's wrong with more assemblys?

   by monser corp

   I agree that misuse assemblies for bad reason are bad, like anything is misused, and your statement gave me the impression that more than 1 assembly is bad. Neither do I agree that assembly is the "most harmful anti-pattern" (what's wrong with implementing logical rule with physical purpose?). I would say some C# language features are create much more bad samples than .net assemblies. For development, the most important is to prevent poor developers from shoting themselves or their teammates. Some times your biggest enemies are your team members. Maybe you are lucky enough to live in a team that have same level as you are and most of them produce good or normal codes. But I don't belive most of developers are as lucky. I once read a statement (can't remember from whom, from uncle bob?) saying most of the project's codes are written by the 2nd worst programmer. Because the good programmers are focusing on the worste ones. And unfortunately my unlucky experience confirmed the statement again and again. I would use whatever it takes to prevent programmers to make mistakes. I would consider the other factors after I've got clean codes.
   
   Personally I would say that compilation performance reason is not so relavent. Pepole who write bad codes does not care waste several mintes on compiling, and I guess those guys have never heard about continous integration or unit testing. Peple who write bad codes does not care about deployment. They have managed to servive (or create?) the dll hell, definitely they'll servive again .net's xcopy deployment.

   Reply

6. Back to top

   Re: What's wrong with more assemblys?

   by monser corp

   Agreed. Clear architecture is more important and some times can be hinted by cycled assembly reference (I recently got one), this will not easily be detected by simple namespace dependecy detection. On the other hand, I would try to prevent errors if possible than detecting errors.
   
   If you want to minimize your assembly numbers, there is a tool, ILMerge which does it. (as long as you don't use too much reflection, it works very good, at least you can merge those static ones in one assembly).

   Reply

7. Back to top

   Re: What's wrong with more assemblys?

   by Nazish Ali Rizvi

   I m with monser corp it happens,but I wanna add something like its not all responsibility of developers its a push from organizations , they need every thing in Eye flash.
   I am trying to implement it in my organization but problem is developers are capped because of business management pressure.

   Reply