NHibernate Tutorial, Part 2 – Modeling Our Domain

This is part 2 of my NHibernate tutorial, make sure to start from part 1.

It’s time to use NHibernate to model our entities.

What are the different ways to model an entity?

NHibernate originally supported two means of entity modeling (both of which are not ideal):

• Xml – using hbm.xml files to define mappings via the nhibernate-mapping-2.0.xsd schema. Xml files on the other hand, are, well, Xml files – they don’t compile and the intellisense is poor. (AND I JUST HATE XML FILES! there, I’ve said it! Meta programming is great in theory but frustrating in practice).
• Attributes – using .Net Attributes from NHibernate.Mapping.Attributes. the attributes create clutter in classes and they couple our entities to NHibernate since unlike Java’s JPA, .Net doesn’t have a common persistence API meaning we have to use NHibernates attributes directly.

Luckily, we now have better alternatives. I’m going to use FluentNHibernate since I really like the simple and elegant API. An alternative is ConfORM, which is integrated in the NHibernate 3.2 release.

Using Fluent NHibernate

Let’s rebuild our domain from scratch, this time even simpler:

Create a new class library named “Entities”, add the following classes:

public class Store

{

    public Store()

    {

        Branches = new HashSet<Branch>();

    }

    public virtual int Id { get; protected set; }

    public virtual string Name { get; set; }

    public virtual Person Contact { get; set; }

    public virtual ICollection<Branch> Branches { get; set; }

}

public class Branch

{

    public virtual int Id { get; set; }

    public virtual Store Store { get; set; }

    public virtual Person Manager { get; set; }

}

public class Person

{

    public virtual int Id { get; set; }

    public virtual string Name { get; set; }

}

It’s important to notice that all of our classes’ properties and methods must be virtual, that’s because of NHibernates use of proxies for lazy loading, but more on that later. For now, you can just use my vprop snippet to save time.

FluentNHibernate (from now on, FNH) maps entities using ClassMaps, which on initialization generate xml that’s similar to NHibernates classic hbm files.

Create a new class library named “Mapping”, since this is where we first use NHibernate we’ll use Nuget to get the dependencies (install SP1 if you haven’t already, it’s in there):

• Right click your project –> “Add Library Package Reference”
  
  
• Search online for FluentNHibernate and install it. notice it depends on NHibernate, which itself depends on other packages:
  
  
• Follow this post to make sure Nuget keeps your dependencies up to date without having to check them into you source control.

Let’s start with mapping our Person class, since it’s the simplest of the three. Add a new class to the mapping project named it PersonMap, it should look something like this:

 

   1: using Entities;

   2: using FluentNHibernate.Mapping;

   3:  

   4: namespace Mapping

   5: {

   6:     public class PersonMap : ClassMap<Person>

   7:     {

   8:         public PersonMap()

   9:         {

  10:             Id(p => p.Id).Column("id").GeneratedBy.Identity();

  11:             Map(p => p.Name).Column("name").Not.Nullable().Length(25);

  12:         }

  13:     }

  14: }

Let’s see what we have here:

• On line 6 you can see we inherit from FNH’s ClassMap<> which makes this class a fluent mapper for Person.
  
  
• On line 10 we define the class’s primary key using a lambda expression, making it refactor friendly. We also define SqlServer identity as the generator for the primary key and “id” as the database column name (later, we’ll use a convention for that, but let’s keep it simple for now). If we don’t define a column name it’ll be the property name by default, and if we don’t define a generator it’s native by default. Read some more here (keep in mind that I use Identity for simplicity, it’s probably NOT the best generator since it has to use the database to generate a new PK).
  
  
• On line 11, again using a lambda expression, we define the Name property as a not nullable, 25 chars long column.

Moving on to the Store map:

 

   1: using Entities;

   2: using FluentNHibernate.Mapping;

   3:  

   4: namespace Mapping

   5: {

   6:     public class StoreMap : ClassMap<Store>

   7:     {

   8:         public StoreMap()

   9:         {

  10:             Id(s => s.Id).Column("id").GeneratedBy.Identity();

  11:             Map(s => s.Name).Column("name").Not.Nullable().Length(25);

  12:  

  13:             References(s => s.Contact);

  14:  

  15:             HasMany(s => s.Branches)

  16:                 .AsSet()

  17:                 .Inverse()

  18:                 .Cascade.SaveUpdate();

  19:         }   

  20:     }

  21: }

Let’s see what we have that’s new:

• Using the References method on line 13 we define Contact as a reference, this will result in a Person foreign key in the Store’s table. I can specify the foreign key’s column name, but the default will be something like Contact_id.
  
  
• Using the HasMany method we define that we have many branches, this will result in a foreign key of Store in the Branches table. We also define:
  
  
  
  
  
  • AsSet – the default behavior is AsBag, while a One-To-Many relation is actually more similar to a Set. Read more here.
    
    
  • Inverse – When defining a one-to-many relation, an update to the database can result in duplicate update statements, since both the “Many” entity and the “One” entity take responsibility for the relation and execute update. Declaring “Inverse” on the relation means “I’m not responsible for updating it”. Usualy the “Many” side is responsible since it holds the foreign key, in our case the Branch will have a reference to Store and that part of the relation will be responsible for updating it.
    
    
  • Cascade – defining the cascade as SaveUpdate means that when saving a new Store or updating an existing one will result in an attempt to save or update the branches in it’s branches collection. Read more here.

Lastly, let’s map our Branch entity:

 

   1: using Entities;

   2: using FluentNHibernate.Mapping;

   3:  

   4: namespace Mapping

   5: {

   6:     public class BranchMap : ClassMap<Branch>

   7:     {

   8:         public BranchMap()

   9:         {

  10:             Id(b => b.Id).Column("id").GeneratedBy.Identity();

  11:  

  12:             References(b => b.Manager);

  13:             References(b => b.Store);

  14:         }

  15:     }

  16: }

Finally, nothing new here.

The previous map will comply to the following database schema:

But for you guys to see it for yourselves, you’ll have to configure a SessionFactory, more on that in the next part – Configuration.