Book Review: NHibernate 3.0 Cookbook by Jason Dentler

by jmorris 28. April 2011 23:06

This is one of the most timely and practical books I have ever read. If you are using NHibernate 3.0 and any of it’s “satellite” FOSS projects and you need a reference on how the community is using it, buy this book.

As the name implies,  the book is laid out in the same manner as a “cookbook” with each chapter grouping together several “recipes”. These recipes illustrate how the community in general is using NHIbernate each feature or API and while they may not cover every scenario, are usually enough to get you going in the right direction.

image

The chapters each cover one of the major components of NHibernate, for instance, there are chapters covering of fundamentals of NHibernate:

  • Models and Mappings
  • Configuration and Schema
  • Session and Transactions
  • Queries

Plus additional chapters on the practical usage of NHibernate:

  • Testing NHibernate
  • Creating a Data Access Layer
  • Extending NHibernate
  • Using the NHibernate Contribution Projects

Each chapter is divided into a series of “recipes”, for instance Using the Conversation per Business Transaction Pattern, and then offers an explanation of what the said topic is or does. Then it goes into sections on:

  • How to do it: detailed description what you need to do to get the example working
  • How it works: detailed description about what is going on behind  the scenes
  • There’s more: any additional information or examples that adds value to the recipe
  • Getting Ready: gives information that is required to get the recipe to work – e.g. download the project binaries from http://code.google.com/p/unhaddins

Pros:

  • Easy to read
  • Packed full of timely examples
  • Layout is easy to follow and comprehend
  • Will get you up and running with NHIbernate very quickly

Cons:

The author’s blog: http://www.jasondentler.com/blog/

Tags: ,

Book Reviews

Comparing ORM's

by jmorris 26. December 2009 09:33

I am currently using Linq, EF, ADO.NET and NHibernate (trying at least) in various projects. Here is my current feeling about each:

  • Linq2Sql - easy, works, obsolete, lacks many features...
  • EF- easy, fast, low barrier to entry...Linq tooling is better than v3.5, which is pretty much useless...v4 seems better
  • ADO.NET - simple, easy, no hidden "gotchas", repetitious, flexible...in most all cases requires framework built around it to scale developer-wise
  • NHibernate - flexible, complex, high barrier to entry, lots of hidden "gotchas" regarding performance, mappings, etc., poor (IMO) query API (syntax), outdated documentation, dedicated community albeit scattered

When one say's NHibernate is missing VS integration, I don't think it's the GUI Modeler that they are missing. It's the fact that they can't point at a database and hit "GO"...I think model first is important, but not everyone works that way.

Low friction prototypes are often the start to more complex finished products. We don't need complexity in prototypes; we tailor our finished works to our problem domain - this is where we tweak the API (away from the GUI) to fit the specific requirements of our problem. The ability to quickly create prototypes from the IDE is incredibly important. Without IDE integration, creating these prototypes is difficult...friction.

The thing that a MS solution offers is IDE integration, which you do not find in the NHibernate suite. If I could go to the NHForge.com site and download a VS plug-in, point at a db, and then start playing...I would be much more inclined to use NHIbernate in a project.

This post was motivated by this post...

Tags: , , ,

Fluent NHibernate Mapping Identity Columns to Properties

by jmorris 1. December 2009 06:37

I decided to jump into the NHibernate lovefest and use it in an upcoming project that I am planning right now. I have been following the NHibernate project for some years, but never actually comitted to using it in a project, because frankly, it was a bit intimidating in size and complexity. Now, of course this was my biased assumption and boy was I wrong! The new Linq 2 NHibernate and Fluent NHibernate API's are awesome and relatively simple to get up and running.

Although I still have some reservations about the completeness and performance of Linq 2 Hibernate, Fluent NHibernate seems to be pretty mature. Additionally, the Fluent NHibernate community is robust, friendly and very quick to lend a hand when I ran into some trouble with AutoMapping.

AutoMapping is a convention based feature of Fluent NHibernate in which with a very little configuration, you can map your entire schema to your domain model. This feature is a tremendous time saver, and gives the illusion of "it just works"! As awesome AutoMapping is, there are certain situations where it will choke. In these cases you must add a little "help" to make the mapping work correctly. Take the following table:

 


Just your basic Role table, but notice how the primary key column is named [entity name]+Id: RoleId? This is a convention that I use for naming the primary keys of all tables I create. It is simple, easy to understand, and works! Now here is the domain model object that it maps to:

 


Notice that the domain object does not have a field called RoleId? Instead we have another field in our base called Id. Now seeing how AutoMapping requires convention (namely naming conventions) to map entities, how does Fluent NHibernate map this with AutoMapping? Well, unfortuntaly it can't:

 



However, with a little help from the Constraints API, we can easily resolve this mapping with a minimum amount of code. What are Conventions, you might ask? According to the Fluent Nhibernate documentation:

"Conventions are small self-contained chunks of behavior that are applied to the mappings Fluent NHibernate generates. These conventions are of varying degrees of granularity, and can be as simple or complex as you require. You should use conventions to avoid repetition in your mappings and to enforce a domain-wide standard consistency."

Connventions are a set of base classes and interfaces that when implemented, allow you to override the default AutoMapping behaviour. Pretty sweet. 

Ok, so how did I resolve the mapping exception above? First the Covention implementation:


And finally the configuration with Fluent NHibernate AutoMapping API:




Tags: , , ,

Decisions, Decisions, Decisions...NHibernate, Linq 2 Sql, or Entity Data Model 4.0?

by jmorris 13. November 2009 08:29

I have a couple of projects coming up and I am trying to decide on a persistence framework to use. I pretty much narrowed the scope down to NHibernate and Fluent NHibernate, Linq2Sql, or Entity Framework 4.0 (there really on 4.0? really?). So far here is my 'superficial' thoughts, feelings about each (note that until I actually commit to one I won't truly understand it's benefits and/or limitations):

  1. NHibernate/Fluent Nhibernate
    1.  Yeas
      1. Cleanly separates persistence layer from domain layer - you can pretty much ignore the database
      2. Strong adoption amongst the 'in-crowd' - many, many Alt.Net and .NET bloggers/developers profess to it's prowess (Ayende, etc)
      3. Supposed strong community
      4. Very configurable - lots of OSS extensions, etc.
    2. Nays
      1. Lack of centralized ownership (IMO) - no single contributer/owner, lots of work outside the main trunk 
      2. Documentation is all over the place; some of it does not seem to be written clearly or lacks steps that require some amount of presupposed knowledge of NHibernate or one of it's dependencies
      3. No support from any of the larger software dev companies
      4. From the main source forge site I don't see much activity; i see more spam that has _not_ been removed than new members.
      5. First implementor syndrome?
  2. Linq2Sql
    1. Yeas
      1. Super simple, limited functionality ORM
      2. Used it, know it, no surprises
      3. Tons of documentation, blog entries, SEO fodder content...everyone has had a turn 
      4. Write code while others configure...
    2. Nays
      1. Obsolete - MS is moving to Entity Framework
      2. Minimalist ORM - you end up adding additional features (such as caching) - this could be a strong point as well
      3. Poor performance with many concurrent users until you optimize (which is relatively easy: compiled queries, etc)
  3. Entity Framework 4.0 
    1. Yeas
      1. Strong MS commitment (or so it seems, unless they have another MS Research project that cannibalizes on this one)
      2. Lots of current documentation
      3. Centralized community (well MS...)
      4. Seems like the have addressed the shortcomings of Entity Framework 3.0 - I won't really know until I commit to using it, the truth always comes out in the implementation
    2. Nays
      1. Previous versions of Entity Framework were horrible
      2. YAMSOSFAS - Yet another Microsoft one size fits all solution
      3. Trust - MS seems to jump from one thing to the next - outside the grokking of us mere mortals; what they support monday might be obsolete on tuesday.
      4. Personal - I always either build it myself or fall back to MS; I need some new experiances ;)
      5. I have worries about the how easy it is to break away from the MS model of horrible code generation experiences. I have seen enough MS brochureware to make me sick for life. I need real world flexibility with MY model, domain, etc. not what MS marketing deems significant.

So that is my initial, superficial perception of each persistence framework. Next up is looking into more specific and less subjective reasons for liking or disliking each ORM solution.


Tags: , , ,

Jeff Morris

Tag cloud

Month List

Page List