"nhibernate" via Marc Climent in Google Reader

Loquacious Configuration in NHibernate 3

2011-01-21T21:54:07Z

[This article was originally published on my personal blog here. I hereby grant myself permission to re-publish it on NHForge.org.]

[Code for this article is available on GitHub here.]

One of the new features in NHibernate 3 is the addition of a fluent API for configuring NHibernate through code. Fluent NHibernate has provided a fluent configuration API for awhile, but now we have an option built into NHibernate itself. (Personally I prefer the new Loquacious API to Fluent NHibernate’s configuration API as I find Loquacious more discoverable. Given that Fluent NHibernate is built on top of NHibernate, you can always use Loquacious with Fluent NHibernate too. N.B. I still really like Fluent NHibernate’s ClassMap<T>, automapping capabilities, and PersistenceSpecification<T>. So don’t take my preference regarding fluent configuration as a denouncement of Fluent NHibernate.)

The fluent configuration API built into NHibernate is called Loquacious configuration and exists as a set of extensions methods on NHibernate.Cfg.Configuration. You can access these extension methods by importing in the NHibernate.Cfg.Loquacious namespace.

var cfg = new Configuration();
cfg.Proxy(p => p.ProxyFactoryFactory<ProxyFactoryFactory>())
   .DataBaseIntegration(db => {
                            db.ConnectionStringName = "scratch";
                            db.Dialect<MsSql2008Dialect>();
                            db.BatchSize = 500;
                        })
   .AddAssembly(typeof(Blog).Assembly)
   .SessionFactory().GenerateStatistics();

On the second line, we configure the ProxyFactoryFactory, which is responsible for generating the proxies needed for lazy loading. The ProxyFactoryFactory type parameter (stuff between the <>) is in the NHibernate.ByteCode.Castle namespace. (I have a reference to the NHibernate.ByteCode.Castle assembly too.) So we’re using Castle to generate our proxies. We could also use LinFu or Spring.

Setting db.ConnectionStringName causes NHibernate to read the connection string from the <connectionStrings/> config section of the [App|Web].config. This keeps your connection strings in an easily managed location without being baked into your code. You can perform the same trick in XML-based configuration by using the connection.connection_string_name property instead of the more commonly used connection.connection_string.

Configuring BatchSize turns on update batching in databases, which support it. (Support is limited to SqlClient and OracleDataClient currently and relies on features of these drivers.) Updating batching allows NHibernate to group together multiple, related INSERT, UPDATE, or DELETE statements in a single round-trip to the database. This setting isn’t strictly necessary, but can give you a nice performance boost with DML statements. The value of 500 represents the maximum number of DML statements in one batch. The choice of 500 is arbitrary and should be tuned for your application.

The assembly that we are adding is the one that contains our hbm.xml files as embedded resources. This allows NHibernate to find and parse our mapping metadata. If you have your metadata located in multiple files, you can call cfg.AddAssembly() multiple times.

The last call, cfg.SessionFactory().GenerateStatistics(), causes NHibernate to output additional information about entities, collections, connections, transactions, sessions, second-level cache, and more. Although not required, it does provide additional useful information about NHibernate’s performance.

Notice that there is no need to call cfg.Configure(). cfg.Configure() is used to read in configuration values from [App|Web].config (from the hibernate-configuration config section) or from hibernate.cfg.xml. If we’ve not using XML configuration, cfg.Configure() is not required.

Loquacious and XML-based configuration are not mutually exclusive. We can combine the two techniques to allow overrides or provide default values – it all comes down to the order of the Loquacious configuration code and the call to cfg.Configure().

var cfg = new Configuration();
cfg.Configure();
cfg.Proxy(p => p.ProxyFactoryFactory<ProxyFactoryFactory>())
   .SessionFactory().GenerateStatistics();

Note the cfg.Configure() on the second line. We read in the standard XML-based configuration and then force the use of a particular ProxyFactoryFactory and generation of statistics via Loquacious configuration.

If instead we make the call to cfg.Configure() after the Loquacious configuration, the Loquacious configuration provides default values, but we can override any and all values using XML-based configuration.

var cfg = new Configuration();
cfg.Proxy(p => p.ProxyFactoryFactory<ProxyFactoryFactory>())
   .DataBaseIntegration(db => {
                            db.ConnectionStringName = "scratch";
                            db.Dialect<MsSql2008Dialect>();
                            db.BatchSize = 500;
                        })
   .AddAssembly(typeof(Blog).Assembly)
   .SessionFactory().GenerateStatistics();
cfg.Configure();

You can always mix and match the techniques by doing some Loquacious configuration before and som after the call to cfg.Configure().

WARNING: If you call cfg.Configure(), you need to have <hibernate-configuration/> in your [App|Web].config or a hibernate.cfg.xml file. If you don’t, you’ll throw a HibernateConfigException. They can contain an empty root element, but it needs to be there. Another option would be to check whether File.Exists(‘hibernate.cfg.xml’) before calling cfg.Configure().

So there you have it. The new Loquacious configuration API in NHibernate 3. This introduction was not meant as a definitive reference, but as a jumping off point. I would recommend that you explore other extension methods in the NHibernate.Cfg.Loquacious namespace as they provide the means to configure the 2nd-leve cache, current session context, custom LINQ functions, and more. Anything you can do in XML-based configuration can now be accomplished with Loquacious or the existing methods on NHibernate.Cfg.Configuration. So get out there and start coding – XML is now optional…

NHibernate Auditing v3 – Poor Man’s Envers

2010-07-05T13:30:00Z

First, let me explain the title of this post. The Hibernate folks – you know, that NHibernate knock off written in the Java (pronounced “ex em el”) programming language – have a project called Envers. Among other things, It audits changes to entities, then allows you to easily retrieve the entity as it was at any previous point in time.

Well, Simon Duduica is porting this over to .NET and NHibernate, and he’s making some AMAZING progress and on June 28th, shared this news with us on the NH Contrib development group:

Hi everybody,

I have news regarding Envers.NET. I've commited a version that works in basic tests for CUD operations, with entities that have relationships between them, also with entities that are not audited. To make things work I had to make two small modifications of NHibernate, both modifications were tested running all NHibernate unit tests and they all passed. I already sent the first modification to Fabio and the second I will send this evening. I would like to thank Tuna for helping me out with good advices when I was stuck :)

So, on to the topic of this post. For NHibernate 3.0 Cookbook, I’ve included a section that explains how to use NHibernate to generate audit triggers. Originally, I had planned to use the code from my previous blog post on the topic, but I didn’t like its structure. I also didn’t want to include all that plumbing code in the printed book. Instead, I’ve rewritten and contributed the “framework” code to uNHAddIns. The “how-to use it” is explained in the book, so I won’t explain it here.

Today, I was writing an integration test for this contribution, and thought the idea was worth sharing. I have a simple Cat class:

When I do anything to this cat, in addition to the normal INSERT, UPDATE, or DELETE, a database trigger records that action in a table called CatAudit:

I wanted an easy way to investigate the contents of this table to prove that my audit triggers worked. Here’s what I came up with, along with help from Jose Romaniello (@jfroma). First, I created a class to match this table:

Next, I mapped it, made it readonly and excluded it from hbm2ddl with this mapping:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
				   assembly="uNhAddIns.Test"
				   namespace="uNhAddIns.Test.Audit.TriggerGenerator">
  <typedef class="NHibernate.Type.EnumStringType`1[[uNhAddIns.Audit.TriggerGenerator.TriggerActions, uNhAddIns]], NHibernate"
           name="triggerActions" />
  <class name="CatAudit" 
         mutable="false"
         schema-action="none">
    <composite-id>
      <key-property name="Id" />
      <key-property name="AuditUser" />
      <key-property name="AuditTimestamp" />
    </composite-id>
    <property name="Color"/>
    <property name="AuditOperation" type="triggerActions" />
  </class>
	
</hibernate-mapping>

I made it readonly by setting mutable="false" and excluded it from hbm2ddl with schema-action="none". Thanks it!

By the way, the <typedef> along with type="triggerActions" just tells NHibernate I've stored my TriggerActions enum values as strings, not numbers.

NHibernate Session Per Request Best Practices

2010-07-01T14:58:00Z

NHibernate used "nadav s" has provided a starter framework that shows a recommend means of starting NHibernate in Web Application. This makes use of IHttpModule to start an NHibernate UnitOfWork and then make sure the UnitOfWork is properly completed. This UnitOfWork checks to see if a transaction is active before ending the request and then cleans up that transaction. It also uses an empty Inversion of Control container to allow further Separation of Concerns

By using an IHttpModule rather than Global.asax the references to NHibernate are totally isolated so that they are external to the Web Application protion of the solution. This reduction in dependancies is desirable to ensure more reliable and maintainable code. The Web Application requires reference to the Framework project, where all the initialization code resides. The only initialization code not in the Framework project is the IHttpModule itself, which is in the Web Application project in the sample. However, even it could be placed in Framework project and still work correctly. The code for the IHttpModule is:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using Framework;

namespace SessionPerRequest
{
    public class UoWHttpModule : IHttpModule
    {
        public void Dispose()
        {

   
        }

        public void Init(HttpApplication context)
        {
            context.BeginRequest += new EventHandler(OnBeginRequest);
            context.EndRequest += new EventHandler(OnEndRequest);
        }


        private void OnBeginRequest(object sender, EventArgs e)
        {
            IUoW uow = IoCContainer.Get<iuowprovider>().Current;
            uow.Init();
        }

        private void OnEndRequest(object sender, EventArgs e)
        {
            IUoW uow = IoCContainer.Get<iuowprovider>().Current;
            uow.End();
        }
    }
}

The OnBeginRequest or OnEndRequest need an IUoW object that is retrieved from WebUoWProvider class:


    internal class WebUoWProvider : IUoWProvider
    {

        public IUoW Current
        {
            get
            {
                WebUoW uow = null;
                if (HttpContext.Current.Items["uow"] == null)
                {   
                    uow = new WebUoW();
                    HttpContext.Current.Items["uow"] = uow;
                }
                else
                {
                    uow = HttpContext.Current.Items["uow"] as WebUoW;
                }

                return uow;
            }

        }

    }

The WebUoWProvider returns a WebUoW class that implements the IUoW interface. The WebUoW class is a wrapper for an NHUoW class that also implements the IUoW interface. First, here is the WebUoW code:

    internal class WebUoW : IUoW
    {
        private NHUoW NHUoW;

        public void Init()
        {
            this.NHUoW = new NHUoW();
            this.NHUoW.Init();
            HttpContext.Current.Items["uow"] = this;
        }

        public void End()
        {
            this.NHUoW.End();
            HttpContext.Current.Items["uow"] = null;
        }

        public void Attach(Entity entity)
        {
            this.NHUoW.Attach(entity);
        }

    }

And then the NHUoW class code:

    internal class NHUoW : IUoW
    {
        protected virtual ISession Session { get; set; }

        public void Init()
        {
            this.Session = SessionFactoryWrapper.Instance.OpenSession();
        }

        public void End()
        {
            if (this.Session != null)
            {
                if (this.Session.Transaction.IsActive)
                {
                    try
                    {
                        this.Session.Transaction.Commit();
                    }
                    catch (Exception ex)
                    {
                        this.Session.Transaction.Rollback();
                        IoCContainer.Get().LogError(ex);
                    }

                    this.Session.Close();
                }
            }
        }

        public void Attach(Entity entity)
        {
            this.Session.Lock(entity, LockMode.None);
        }
    }

The WebUoW class wraps an NHUoW class so that the same framework can be used for testing without having a Web Application running, as would be the case when using the NUnit console. The NHUoW class does a clean up if the Web Request ends before the application closes an active transaction. If the Web application were an exceptionally simple one it would be possible to put a BeginTransaction call in the NHUoW Init call.

The sample solution from "nadav s" can be download from here. I will be using this as a starting point to complete a working solution for an NH3.0 sample application that will be described further in another blog.

NHibernate: Mappings path

2010-03-03T03:29:00Z

In the last Alt.NET café, about ConfORM, I noticed a confusion about NHibernate’s mappings management. The image below show a simplified schema of the “mapping process”, the entry-point of some frameworks and the entry point of my examples : This schema is working since NHibernate 2.0.0GA (2008-08-23) Between NH2.0.0 and the actual trunk, what we have done is transform the usage of

NHibernate vs. Entity Framework 4.0

2010-01-05T10:00:00Z

This is a question that I get very frequently, and I always tried to dodged the bullet, but I get it so much that I feel that I have to provide an answer. Obviously, I am (not so) slightly biased toward NHibernate, so while you read it, please keep it in mind.

EF 4.0 has done a lot to handle the issues that were raised with the previous version of EF. Thinks like transparent lazy loading, POCO classes, code only, etc. EF 4.0 is a much nicer than EF 1.0.

The problem is that it is still a very young product, and the changes that were added only touched the surface. I already talked about some of my problems with the POCO model in EF, so I won’t repeat that, or my reservations with the Code Only model. But basically, the major problem that I have with those two is that there seems to be a wall between what experience of the community and what Microsoft is doing. Both of those features shows much of the same issues that we have run into with NHibernate and Fluent NHibernate. Issues that were addressed and resolved, but show up in the EF implementations.

Nevertheless, even ignoring my reservations about those, there are other indications that NHibernate’s maturity makes itself known. I run into that several times while I was writing the guidance for EF Prof, there are things that you simple can’t do with EF, that are a natural part of NHibernate.

I am not going to try to do a point by point list of the differences, but it is interesting to look where we do find major differences between the capabilities of NHibernate and EF 4.0. Most of the time, it is in the ability to fine tune what the framework is actually doing. Usually, this is there to allow you to gain better performance from the system without sacrificing the benefits of using an OR/M in the first place.

Here is a small list:

Write batching – NHibernate can be configured to batch all writes to the database so that when you need to write several statements to the database, NHibernate will only make a single round trip, instead of going to the database per each statement.
Read batching / multi queries / futures – NHibernate allows to batch several queries into a single round trip to the database, instead of separate roundtrip per each query.
Batched collection loads – When you lazy load a collection, NHibernate can find other collections of the same type that weren’t loaded, and load all of them in a single trip to the database. This is a great way to avoid having to deal with SELECT N+1.
Collection with lazy=”extra” – Lazy extra means that NHibernate adapts to the operations that you might run on top of your collections. That means that blog.Posts.Count will not force a load of the entire collection, but rather would create a “select count(*) from Posts where BlogId = 1” statement, and that blog.Posts.Contains() will likewise result in a single query rather than paying the price of loading the entire collection to memory.
Collection filters and paged collections - this allows you to define additional filters (including paging!) on top of your entities collections, which means that you can easily page through the blog.Posts collection, and not have to load the entire thing into memory.
2nd level cache – managing the cache is complex, I touched on why this is important before, so I’ll skip if for now.
Tweaking – this is something that is critical whenever you need something that is just a bit beyond what the framework provides. With NHibernate, in nearly all the cases, you have an extension point, with EF, you are completely and utterly blocked.
Integration & Extensibility – NHibernate has a lot of extension projects, such as NHibernate Search, NHibernate Validator, NHibernate Shards, etc. Such projects not only do not exists for EF, but they cannot be written, for the most part, because EF has no extension points to speak of.

On the other side, however:

EF 4.0 has a better Linq provider than the current NHibernate implementation. This is something being actively worked on and the NH 3.0 will fix this gap.
EF is from Microsoft.

QueryOver in NH 3.0

2009-12-17T23:22:00Z

Introduction

The ICriteria API is NHibernate's implementation of Query Object. NHibernate 3.0 introduces the QueryOver api, which combines the use of Extension Methods and Lambda Expressions (both new in .Net 3.5) to provide a statically typesafe wrapper round the ICriteria API.

QueryOver uses Lambda Expressions to provide some extra syntax to remove the 'magic strings' from your ICriteria queries.

So, for example:

.Add(Expression.Eq("Name", "Smith"))

becomes:

.Where<Person>(p => p.Name == "Smith")

With this kind of syntax there are no 'magic strings', and refactoring tools like 'Find All References', and 'Refactor->Rename' work perfectly.

Note: QueryOver is intended to remove the references to 'magic strings' from the ICriteria API while maintaining it's opaqueness. It is not a LINQ provider; NHibernate 3.0 has a built-in Linq provider for this.

Structure of a Query

Queries are created from an ISession using the syntax:

IList<Cat> cats =
    session.QueryOver<Cat>()
        .Where(c => c.Name == "Max")
        .List();

Detached QueryOver (analagous to DetachedCriteria) can be created, and then used with an ISession using:

QueryOver<Cat> query =
    QueryOver.Of<Cat>()
        .Where(c => c.Name == "Paddy");
        
IList<Cat> cats =
    query.GetExecutableQueryOver(session)
        .List();

Queries can be built up to use restrictions, projections, and ordering using a fluent inline syntax:

var catNames =
    session.QueryOver<Cat>()
        .WhereRestrictionOn(c => c.Age).IsBetween(2).And(8)
        .Select(c => c.Name)
        .OrderBy(c => c.Name).Asc
        .List<string>();

Simple Expressions

The Restrictions class (used by ICriteria) has been extended to include overloads that allow Lambda Expression syntax. The Where() method works for simple expressions (<, <=, ==, !=, >, >=) so instead of:

ICriterion equalCriterion = Restrictions.Eq("Name", "Max")

You can write:

ICriterion equalCriterion = Restrictions.Where<Cat>(c => c.Name == "Max")

Since the QueryOver class (and IQueryOver interface) is generic and knows the type of the query, there is an inline syntax for restrictions that does not require the additional qualification of class name. So you can also write:

var cats =
    session.QueryOver<Cat>()
        .Where(c => c.Name == "Max")
        .And(c => c.Age > 4)
        .List();

Note, the methods Where() and And() are semantically identical; the And() method is purely to allow QueryOver to look similar to HQL/SQL.

Boolean comparisons can be made directly instead of comparing to true/false:

        .Where(p => p.IsParent)
        .And(p => !p.IsRetired)

Simple expressions can also be combined using the || and && operators. So ICriteria like:

        .Add(Restrictions.And(
            Restrictions.Eq("Name", "test name"),
            Restrictions.Or(
                Restrictions.Gt("Age", 21),
                Restrictions.Eq("HasCar", true))))

Can be written in QueryOver as:

        .Where(p => p.Name == "test name" && (p.Age > 21 || p.HasCar))

Each of the corresponding overloads in the QueryOver API allows the use of regular ICriterion to allow access to private properties.

        .Where(Restrictions.Eq("Name", "Max"))

It is worth noting that the QueryOver API is built on top of the ICriteria API. Internally the structures are the same, so at runtime the statement below, and the statement above, are stored as exactly the same ICriterion. The actual Lambda Expression is not stored in the query.

        .Where(c => c.Name == "Max")

Additional Restrictions

Some SQL operators/functions do not have a direct equivalent in C#. (e.g., the SQL where name like '%anna%'). These operators have overloads for QueryOver in the Restrictions class, so you can write:

        .Where(Restrictions.On<Cat>(c => c.Name).IsLike("%anna%"))

There is also an inline syntax to avoid the qualification of the type:

        .WhereRestrictionOn(c => c.Name).IsLike("%anna%")

While simple expressions (see above) can be combined using the || and && operators, this is not possible with the other restrictions. So this ICriteria:

        .Add(Restrictions.Or(
            Restrictions.Gt("Age", 5)
            Restrictions.In("Name", new string[] { "Max", "Paddy" })))

Would have to be written as:

        .Add(Restrictions.Or(
            Restrictions.Where<Cat>(c => c.Age > 5)
            Restrictions.On<Cat>(c => c.Name).IsIn(new string[] { "Max", "Paddy" })))

Associations

QueryOver can navigate association paths using JoinQueryOver() (analagous to ICriteria.CreateCriteria() to create sub-criteria).

The factory method QuerOver<T>() on ISession returns an IQueryOver<T>. More accurately, it returns an IQueryOver<T,T> (which inherits from IQueryOver<T>).

An IQueryOver has two types of interest; the root type (the type of entity that the query returns), and the type of the 'current' entity being queried. For example, the following query uses a join to create a sub-QueryOver (analagous to creating sub-criteria in the ICriteria API):

IQueryOver<Cat,Kitten> catQuery =
    session.QueryOver<Cat>()
        .JoinQueryOver(c => c.Kittens)
            .Where(k => k.Name == "Tiddles");

The JoinQueryOver returns a new instance of the IQueryOver than has its root at the Kittens collection. The default type for restrictions is now Kitten (restricting on the name 'Tiddles' in the above example), while calling .List() will return an IList<Cat>. The type IQueryOver<Cat,Kitten> inherits from IQueryOver<Cat>.

Note, the overload for JoinQueryOver takes an IEnumerable<T>, and the C# compiler infers the type from that. If your collection type is not IEnumerable<T>, then you need to qualify the type of the sub-criteria:

IQueryOver<Cat,Kitten> catQuery =
    session.QueryOver<Cat>()
        .JoinQueryOver<Kitten>(c => c.Kittens)
            .Where(k => k.Name == "Tiddles");

The default join is an inner-join. Each of the additional join types can be specified using the methods .Inner, .Left, .Right, or .Full. For example, to left outer-join on Kittens use:

IQueryOver<Cat,Kitten> catQuery =
    session.QueryOver<Cat>()
        .Left.JoinQueryOver(c => c.Kittens)
            .Where(k => k.Name == "Tiddles");

Aliases

In the traditional ICriteria interface aliases are assigned using 'magic strings', however their value does not correspond to a name in the object domain. For example, when an alias is assigned using .CreateAlias("Kitten", "kittenAlias"), the string "kittenAlias" does not correspond to a property or class in the domain.

In QueryOver, aliases are assigned using an empty variable. The variable can be declared anywhere (but should be empty/default at runtime). The compiler can then check the syntax against the variable is used correctly, but at runtime the variable is not evaluated (it's just used as a placeholder for the alias).

Each Lambda Expression function in QueryOver has a corresponding overload to allow use of aliases, and a .JoinAlias function to traverse associations using aliases without creating a sub-QueryOver.

Cat catAlias = null;
Kitten kittenAlias = null;

IQueryOver<Cat,Cat> catQuery =
    session.QueryOver<Cat>(() => catAlias)
        .JoinAlias(() => catAlias.Kittens, () => kittenAlias)
        .Where(() => catAlias.Age > 5)
        .And(() => kittenAlias.Name == "Tiddles");

Projections

Simple projections of the properties of the root type can be added using the .Select method which can take multiple Lambda Expression arguments:

IList selection =
    session.QueryOver<Cat>()
        .Select(
            c => c.Name,
            c => c.Age)
        .List<object[]>();

Because this query no longer returns a Cat, the return type must be explicitly specified. If a single property is projected, the return type can be specified using:

IList<int> ages =
    session.QueryOver<Cat>()
        .Select(c => c.Age)
        .List<int>();

However, if multiple properties are projected, then the returned list will contain object arrays, as per a projection in ICriteria. This could be fed into an anonymous type using:

var catDetails =
    session.QueryOver<Cat>()
        .Select(
            c => c.Name,
            c => c.Age)
        .List<object[]>()
        .Select(properties => new {
            CatName = (string)properties[0],
            CatAge = (int)properties[1],
            });
            
Console.WriteLine(catDetails[0].CatName);
Console.WriteLine(catDetails[0].CatAge);

Note that the second .Select call in this example is an extension method on IEnumerable<T> supplied in System.Linq; it is not part of NHibernate.

QueryOver allows arbitrary IProjection to be added (allowing private properties to be projected). The Projections factory class also has overloads to allow Lambda Expressions to be used:

IList selection =
    session.QueryOver<Cat>()
        .Select(Projections.ProjectionList()
            .Add(Projections.Property<Cat>(c => c.Name))
            .Add(Projections.Avg<Cat>(c => c.Age)))
        .List<object[]>();

In addition there is an inline syntax for creating projection lists that does not require the explicit class qualification:

IList selection =
    session.QueryOver<Cat>()
        .SelectList(list => list
            .Select(c => c.Name)
            .SelectAvg(c => c.Age))
        .List<object[]>();

Projections can also have arbitrary aliases assigned to them to allow result transformation. If there is a CatSummary DTO class defined as:

public class CatSummary
{
    public string Name { get; set; }
    public int AverageAge { get; set; }
}

... then aliased projections can be used with the AliasToBean<T> transformer:

CatSummary summaryDto = null;
IList<CatSummary> catReport =
    session.QueryOver<Cat>()
        .SelectList(list => list
            .SelectGroup(c => c.Name).WithAlias(() => summaryDto.Name)
            .SelectAvg(c => c.Age).WithAlias(() => summaryDto.AverageAge))
        .TransformUsing(Transformers.AliasToBean<CatSummary>())
        .List<CatSummary>();

Subqueries

The Subqueries factory class has overloads to allow Lambda Expressions to express sub-query restrictions. For example:

QueryOver<Cat> maximumAge =
    QueryOver.Of<Cat>()
        .SelectList(p => p.SelectMax(c => c.Age));

IList<Cat> oldestCats =
    session.QueryOver<Cat>()
        .Where(Subqueries.WhereProperty<Cat>(c => c.Age).Eq(maximumAge))
        .List();

The inline syntax allows you to use subqueries without requalifying the type:

IList<Cat> oldestCats =
    session.QueryOver<Cat>()
        .WithSubquery.WhereProperty(c => c.Age).Eq(maximumAge)
        .List();

There is an extension method As() on (a detached) QueryOver that allows you to cast it to any type. This is used in conjunction with the overloads Where(), WhereAll(), and WhereSome() to allow use of the built-in C# operators for comparison, so the above query can be written as:

IList<Cat> oldestCats =
    session.QueryOver<Cat>()
        .WithSubquery.Where(c => c.Age == maximumAge.As<int>())
        .List();

Linq to NHibernate Progress Report - A Christmas Gift?

2009-12-17T00:00:00Z

Time for another progress report, and this one's a biggie :)

Barring a couple of pretty minor things that won't take much fixing, all the original Linq tests have now been ported over to the new provider and are all passing. That means the new provider is now (from the perspective of the tests, at least) in better shape that the version 1 provider. It can do everything the original provider could, plus a whole bunch more. A couple of example queries that now work just fine are:

  from e in db.Employees   from et in e.Territories   where e.Address.City == "Seattle"   select new {e.FirstName, e.LastName, et.Region.Description};
  from c in db.Customers   join o in db.Orders on c.CustomerId equals o.Customer.CustomerId into orders   select new {c.ContactName, OrderCount = orders.Average(x => x.Freight)};
  from o in db.Orders   from p in db.Products   join d in db.OrderLines on new {o.OrderId, p.ProductId} equals new {d.Order.OrderId, d.Product.ProductId}    into details   from d in details   select new {o.OrderId, p.ProductId, d.UnitPrice}
  from c in db.Customers   join o in db.Orders on c.CustomerId equals o.Customer.CustomerId   group o by c into x   select new { CustomerName = x.Key.ContactName, Order = x }

(ignore whether those queries make any real sense, it's just the form of them that matters)

So, more importantly, what doesn't work? Well, out of the tests that we've currently got, not a huge amount. Some important areas that are missing are:

Nested selects to produce hierarchical output. I've got some prototype code for doing this, so it will be supported at some point but isn't there right now. Of course, since NH already understands relationships, nested selects are far less important than they are for something like Linq to SQL.
Group joins that produce hierarchical output - these essentially boil down to the same code as the nested select case, so support for these will probably come at around the same time. Group joins that don't introduce a hierarchy should work just fine.
Set operations, such as Union and Intersect. Union you can obviously do yourself in client code with no particular overhead. Intersect would really be better in the provider :)
Left outer join style queries, such as:

from e in db.Employees join o in db.Orders on e equals o.Employee into ords from o in ords.DefaultIfEmpty() select new {e.FirstName, e.LastName, Order = o}; This is a fairly widely used construct, so is close to top of the list for future support
Let expressions, such as:

from c in db.Customers join o in db.Orders on c.CustomerId equals o.Customer.CustomerId into ords let z = c.Address.City + c.Address.Country from o in ords select new {c.ContactName, o.OrderId, z}; Again, this is quite high on the TODO list.
Support for custom functions. This is actually fully implemented internally, but I just want to review the API usage before I tell you all how to use it - it probably needs a little cleanup from it's current state, but I don't anticipate any major changes.

I've also got a number of TODOs, but mainly cleanup rather than functional, plus I need to work through the error handling to ensure that any queries that are passed in that the provider can't handle are rejected gracefully rather than just barfing (which is the likely case right now).

The only gotcha that I know of is a query that runs just fine but doesn't necessarily return the correct number of results. Specifically, queries like this:

from user in db.Users select new { user.Name, RoleName = user.Role.Name };

Right now, this generates a join to the Role table, so any users that don't have a role are not returned. This differs from Linq to SQL where a left join is generated, giving a null RoleName for any users without a role. I believe the Linq to SQL implementation to be correct - the above query doesn't explicitly have any form of filtering (where clause, join clause etc), so you should get back all the users in the database. This one is top of the list, and hopefully will be fixed soon (it's not hard, I've just run out of time!).

In summary, I'm getting pretty happy with the state of the provider and think that it's now ready for general usage - although there are still some important query forms to support, I think there's sufficient there now to do useful work. If you've got good test coverage, then I'd even be happy for it to go live. If you don't have good coverage, then don't come crying to me :)

Of course, this is all in the trunk, so anyone wanting to play either needs to get the trunk source and build it, or take the much easier option of having Horn do the work. Horn builds the trunk on a daily basis, so look for a package built after around 2300GMT on the 16/12/2009 (the package URL on Horn has the datetime stamp in it, so it's pretty easy to spot).

I'm on holiday for the next couple of weeks, and will only have intermittent internet access. However, ping me either by email or twitter with comments / bugs / suggestions, and I'll do my best to reply. Normal service (whatever that is) will return around Jan 4th.

Linq, NHibernate

La herencia mal planteada

2009-12-07T21:55:00Z

En cuestiones de ORM (Object Relational Mapping) casi siempre asociamos una relación uno a uno (1:1) en bases de datos relacionales, con una herencia de clases. Esquematizar este tipo de diseño puede llevarnos a futuros errores cuando nos planteamos la arquitectura de cualquier proyecto.

Vamos a ver ejemplos que nos permitan entender dónde está la trampa.

Si tratamos de representar la estructura de mascotas en un diagrama de clases, pudiéramos pensar que todas tienen un dueño, al igual que todas tienen un nombre y una fecha de nacimiento. De ahí, y derivando en acciones más específicas, vemos que algunas mascotas se pueden acariciar (perro, gato), y otras no tanto (por ejemplo una serpiente, sí sí, una serpiente, que dueños locos se sobran en este mundo).

Representando esto, tendríamos una clase mascota, que tendría una propiedad persona (dueño), otra propiedad fecha de nacimiento, y todas aquellas que entendamos pueden ser comunes a todas las mascotas. Luego, cada mascota, heredaría su funcionalidad e implementaría sus funciones más específicas (no quiero complicar el diagrama porque al final no es el objetivo de este artículo)

Este diagrama, traducido a una base de datos relacional, nos quedaría con tres tablas, mascota, perro y serpiente, donde tendríamos una relación de uno a uno entre ellas, y cualquier ORM decente, sabría que leer un perro implica leer la información asociada al mismo en la tabla mascota, y lo mismo ocurriría si tratamos de insertar o actualizar cualquiera de las clases que implementen mascota.

Pero… (Siempre hay un pero)

Si analizamos esto mismo con alumnos y maestros, ¿qué pasaría? Vamos allá…

Un maestro, al igual que un alumno, son personas, ambos tienen un nombre, apellidos, padres, edad, etc. Mientras más elementos en común tengan varias clase, más confirmamos la presencia de una herencia, así que si llevamos esto a un diagrama de clases, nos quedaría de la siguiente forma:

Visto desde el punto de vista de bases de datos, igual caeríamos en tres tablas, con una relación uno a uno entre ellas (persona, maestro y alumno) y todo perfecto con el ORM. Todo perfecto hasta que a un maestro se le ocurre estudiar. Plantearnos esta situación nos crea un problema, ¿cómo digo yo que un maestro también es un alumno? ¿Cómo puedo asumir que una misma persona ahora es estudiante y maestro?

La encapsulación de la propia herencia no lo permite, yo no podría reutilizar la información de persona ahora en alumno, por lo que aquí la herencia no aplica y, la solución pasa por convertir la herencia, en una asociación de Persona tanto en la clase Maestro como en la clase Alumno, o como una alternativa, pudiéramos definir una lista de responsabilidades asociadas a una persona, de manera que pudiera ocupar la función de alumno y maestro al mismo tiempo.

¿Cómo podemos identificar este tipo de problema cuando nos enfrentamos a un diseño de cualquier aplicación?

Roles que definen responsabilidad

Los roles son actividades que pueden ser compartidas por un elemento de nuestro diseño, siempre que exista un mismo objeto que pueda compartir más de un rol, la herencia no es la solución. Es por esto que en el análisis de mascotas esto no ocurre, ya que un perro no podrá ser nunca una serpiente y tampoco viceversa, al menos hasta hoy ;)

Fabio Maulo, team leader de para mí el mejor ORM que existe hoy en día, NHibernate, hace mucho tiempo hacía una historia sobre un personaje que vive en las colinas de Italia y que ejemplificaba este problema con la herencia.

Salu2

NHibernate.Validator: Tags

2009-11-17T23:21:00Z

At the begin of NHibernate Validator we have talked about the exigency of assign a “gravity level” to each validation (for instance Error, Warning, Information). In the last year we had requests for “validation grouping” and “different validation, for the same entity, in different contexts”. Our answer is: validation tagging What is a tag In NHibernate Validator a tag has de same meaning you are

NHibernate.Validator : Customizing messages (Message Interpolator)

2009-10-28T10:00:00Z

The message interpolator is the responsible of the messages translation/composition. In the coming soon version (NHV-1.2.0) we had increase its power (and refactorized its implementation). Has default NHV has two implementations: DefaultMessageInterpolatorAggregator and DefaultMessageInterpolator. What is the usual you have seen in NHibernate’s eco-system ? Yes, you are right: Injectability!!!

NHibernate Validator 1.2 Beta3 released

2009-10-26T16:12:00Z

Download NHibernate Validator 1.2 beta3 with sources, binaries and example here here

For use it with NHibernate 2.1 GA.

For examples and documentation see the serie of blog posts of Fabio Maulo about NHibernate Validator here

NHibernate.Validator : Extending ValidationDef

2009-10-26T08:00:00Z

In various applications I’m using my implementation of Range. public interface IRange<T> : IEquatable<IRange<T>> where T : IComparable<T>{T LowLimit { get; }T HighLimit { get; }bool IsEmpty { get; }bool Includes(T value);bool Includes(IRange<T> other);bool Overlaps(IRange<T> other);}As you can imagine I’m using it to represent various kind of ranges and in each usage I need to validate the range

NHibernate webcasts series

2009-10-24T10:12:00Z

Rob Conery and I had sat down and started recording a series of webcasts on NHibernate, which will show up on TekPub. TekPub is a paid service, and there are two NHibernate screen casts there already. We plan to have lots more.

I got a lot of requests for making my NHibernate courses available to a wider audience. And this is a way for you to get a ton of NHibernate content. So far the reactions that we got were very positive.

Oh, and as a side effect, you get to see NH Prof used by the person who wrote it, you might learn a thing or two about extracting information from the profiler.

NHibernate.Validator : The “Satisfy” way of custom Validators

2009-10-24T10:00:00Z

The Satisfy (perhaps it sound familiar to some SharpTestsEx users ;) ). To show how it work the example is a constraint for Person.Name: a Name is significant when it has more than three characters, is composed by letters and the first letter is in uppercase. To create a that validator, in the classic way, we should create an Attribute implementing IRuleArgs and then a class implementing

A S#arp Project Case Study

2009-10-08T18:55:00Z

Like Jimmy Bogard, I was pleased to read a post from Howard van Rooijen on the S#arp Architecture forums concerning the use of S#arp Architecture and Bogard's AutoMapper in the timely development of http://www .fancydressoutfitters.co.uk. With a big thanks to Howard, he has also taken the time to provide a number of great blog posts which walk the reader through his experiences, challenges, solutions, and lessons learned with respect to developing a commercial, greenfield application using ASP.NET MVC.

Hello S#arp Architecture Community,

I just wanted to let you know that a S#arp Architecture based e-commerce site has just been released into the wild: http://www.fancydressoutfitters.co.uk

For those who are interested - here's a little background:

- We ran the project using Scrum (managing the project with Scrum for Team System)

- Delivered in 20 weeks: 10 x 2 week iterations
- We extended the core S#arp Architecture framework (support for multiple databases, ViewModels etc...)
- Integrated other OSS projects into the solution:
  - N2CMS
  - Spark View Engine
  - xVal Validation Framework
  - AutoMapper (for entity / view model mapping)
  - PostSharp (for cross cutting concerns - logging, performance counters, caching)
  - MBUnit / Gallio for our BDD Framework
  - Solr & SolrNet for Search and Faceted Navigation
- Over 700 BDD Specs
- Solution performs very well - 1000 concurrent users per web server, generating around 180 pages per second across 2x single quad core 64bit servers.

If you're really interested two of the developers in the team (James Broome & Jon George who have both posted to this forum) & myself have blogged our thoughts & experiences developing this solution and working with S#arp Architecture:

I wanted to say a HUGE thank-you to everyone in this community for all the passion, energy, knowledge and help you provide on a daily basis.

S#arp Architecture is a wonderful framework that truly is greater than the sum of its parts.

/Howard

Thanks for sharing Howard and good luck with the venture! (There are other S#arp projects in the wild discussed in the S#arp forums...go take a look!)

Billy McCafferty

Choosing between Active Record, Fluent NHibernate and NHibernate

2009-10-08T16:42:00Z

A forum question:

I have seen videos where you created a domain model using ActiveRecord in real-time... elaborate on when and how you move to using full Hibernate in more detail.

The problem with presentations such as the one described in the question is that they are cheating. Oh, I really do work things on the fly, but it is like asking me to type with my eyes closed (as I am doing right now, just to see if I can).

I can do that, but it doesn’t really say much about my typing skills. The type of models that I create live tend to be very simple ones, things that I have done for dozens and hundreds of times. Building a model live on stage looks impressive, especially since I insist of the people in the audience picking the model. But it really isn’t that hard.

That said, the actual question is more interesting, what should you choose? Active Record, Fluent NHibernate or mapping files?

I, personally, like using mapping files, they are simple, uncomplicated and expose everything that NHibernate can do. Active Record is nice if you want to put the persistence definition right there along the class definition. Another major advantage of Active Record is that it is working hard to infer things for you. It makes working with it very easy.

Fluent NHibernate is mapping using C#. I don’t quite see the point there, especially since in some things FN decided to diverge from the NHibernate terminology, but I get why people love it. The part about it that I simply adore is the auto mapping support. That is a great way of getting things started.

But usually, even if I am using Fluent NHibernate or Active Record, I am mostly using them as scaffolding. At some point, I’ll ask them to generate the HBM for me and start working with them.

That is me, however, your mileage might vary.

How you shouldn’t write your mapping

2009-10-03T16:46:00Z

More than one time, in my courses, in this blog and in various NH’s users list, I talked about a rule of thumb about mappings: not try to be clear because it obscures. Have a look to this mapping:

Quick news: NHibernate with SQL-Azure

2009-09-28T15:38:00Z

Just ran DAOs integration tests (the same of this post) in SQL-AZURE. All work… even the SchemaExport. well…well… Not all glitters is gold ;) Exception: “Heaps can not be replicated tables. Please create a clustered index for the table.”

Avoid Soft Deletes

2009-08-30T19:27:00Z

One of the annoyances that we have to deal when building enterprise applications is the requirement that no data shall be lost. The usual response to that is to introduce a WasDeleted or an IsActive column in the database and implement deletes as an update that would set that flag.

Simple, easy to understand, quick to implement and explain.

It is also, quite often, wrong.

The problem is that deletion of a row or an entity is rarely a simple event. It effect not only the data in the model, but also the shape of the model. That is why we have foreign keys, to ensure that we don’t end up with Order Lines that don’t have a parent Order. And that is just the simplest of issues. Let us consider the following model:

public class Order
{
    public virtual ICollection<OrderLines> OrderLines { get;set; }
}

public class OrderLine
{
    public virtual Order Order { get;set; }
}

public class Customer
{
    public virtual Order LastOrder { get;set; }
}

Let us say that we want to delete an order. What should we do? That is a business decision, actually. But it is one that is enforced by the DB itself, keeping the data integrity.

When we are dealing with soft deletes, it is easy to get into situations where we have, for all intents and purposes, corrupt data, because Customer’s LastOrder (which is just a tiny optimization that no one thought about) now points to a soft deleted order.

Now, to be fair, if you are using NHibernate there are very easy ways to handle that, which actually handle cascades properly. It is still a more complex solution.

For myself, I much rather drop the requirement for soft deletes in the first place and head directly to why we care for that. Usually, this is an issue of auditing. You can’t remove data from the database once it is there, or the regulator will have your head on a silver platter and the price of the platter will be deducted from your salary.

The fun part is that it is so much easier to implement that with NHibernate, for that matter, I am not going to show you how to implement that feature, I am going to show how to implement a related one and leave building the auditable deletes as an exercise for the reader :-)

Here is how we implement audit trail for updates:

public class SeparateTableLogEventListener : IPreUpdateEventListener
{
    public bool OnPreUpdate(PreUpdateEvent updateEvent)
    {
        var sb = new StringBuilder("Updating ")
            .Append(updateEvent.Entity.GetType().FullName)
            .Append("#")
            .Append(updateEvent.Id)
            .AppendLine();

        for (int i = 0; i < updateEvent.OldState.Length; i++)
        {
            if (Equals(updateEvent.OldState[i], updateEvent.State[i])) continue;

            sb.Append(updateEvent.Persister.PropertyNames[i])
                .Append(": ")
                .Append(updateEvent.OldState[i])
                .Append(" => ")
                .Append(updateEvent.State[i])
                .AppendLine();
        }

        var session = updateEvent.Session.GetSession(EntityMode.Poco);
        session.Save(new LogEntry
        {
            WhatChanged = sb.ToString()
        });
        session.Flush();

        return false;
    }
}

It is an example, so it is pretty raw, but it should be create what is going on.

Your task, if you agree to accept it, is to build a similar audit listener for deletes. This message will self destruct whenever it feels like.

Fluent NHibernate 1.0

2009-08-29T00:33:00Z

The 1.0 RTM is now available here.

For those of you that don't know, Fluent NHibernate is for helping you map entities with NHibernate. It's based firmly on the practice of convention-over-configuration, and can be used in a mapping-per-class style using our fluent interface, or let our automapper map your entities itself.

This release introduces a few significant changes, and a lot of insignificant ones. You should refer to the 1.0 release notes for an overview of what's changed.

The wiki has also been upgraded to use different software which should hopefully stop people being blocked, and make it a bit more stable; the upgrade included completely rewriting all of the pages, so don't anyone say that it's out of date.

You can get the binaries from the our downloads page, or get the source from the github site.

Special thanks go out to the Fluent NHibernate team, Paul Batum, Hudson Akridge, Andrew Stewart, and Stuart Childs. Each of them has put in time and effort above what was asked of them, and they've all felt guilty when not contributing, which is great. Thanks also to all the testers and contributors we've had over the months. Specifically Darko Conrad, for finding about 30 separate issues with the release candidiate; Everett Muniz and his subclasses, who now has a test of his own; and Kevin Dente, for deciding to moan about our method names only after months of work and a release candidate. I owe everyone beers if ever I'm in your area.

Fabio Maulo, Ayende, and the rest of the NHibernate team: Thanks for a great tool. NHibernate is a shining example of all that is good in open source in the .Net world.

...and with that, I'm going on holiday.