Can someone better explain what 'Projections' are in nHibernate?

Derek picture Derek · May 26, 2011 · Viewed 15.3k times · Source

As a new user of nHibernate and its utility library, fluent nhibernate, I am trying to learn enough to be dangerous with a good database.

I am having an exceptionally great deal of difficulty understanding the concept of Projections. Specifically, What in the world are they?

I have literally done exact searches on 'What are projections?' and 'Projects in nHibernate' and 'nHibernate, Projections, Definition', etc. And I am still very confused. The most helpful posts so far are This other StackOverflow Question and This Blog Post by Colin Ramsay. But I am still vastly confused. My knowledge of databases is still entry-level at best.

I do not really understand what projections are, why I would want to use them, what they are accomplishing, etc. I see in the blog post that he is using them to get a list of integers (I presume Primary Keys) so that he can use them in a different query, but this is kind of nebulous in the way it is functioning and the why.

Answer

Nicholas Piasecki picture Nicholas Piasecki · May 26, 2011

Here's a practical example.

Let's say that you have an online store and one of your domain classes is a Brand like "Samsung". This class has a boatload of properties associated with it, perhaps an integer Identity, a Name, a free-text Description field, a reference to a Vendor object, and so on.

Now let's say that you want to display a menu with a list of all the brands offered on your online store. If you just do session.CreateCriteria<Brand>().List(), then you are indeed going to get all of the brands. But you'll also have sucked all of the long Description fields and references to Vendors from the database, and you don't need that to display a menu; you just need the Name and the Identity. Performance-wise, sucking all of this extra data down from the database slows things down and is unnecessary.

Instead, you can create a "projection" object that contains just the Identity and the Name calling it, say, NameIdentityPair:

public class NameIdentityPair
{
    public int Identity { get; set; }
    public string Name { get; set; }
}

And you could tell NHibernate to only select the data that you really need to perform the task at hand by telling it to transform the result set onto your projection:

var brandProjections = this.session.CreateCriteria<Brand>()
    .SetProjection(Projections.ProjectionList()
        .Add(Projections.Property("Name"), "Name")
        .Add(Projections.Property("Identity"), "Identity"))
    .SetResultTransformer(Transformers.AliasToBean<NameIdentityPair>())
    .List<NameIdentityPair>();

foreach (var brandProjection in brandProjections)
{
    Console.WriteLine(
        "Identity: {0}, Name: {1}", 
        brandProjection.Identity, 
        brandProjection.Name);
}

Now you don't have a list of Brands but instead a list of NameIdentityPairs, and NHibernate will have only issued a SQL statement like SELECT b.Identity, b.Name from dbo.Brand b to obtain this projection, as opposed to a massive SQL statement that grabs everything necessary to hydrate a Brand object (e.g., SELECT b.Identity, b.Name, b.Description from dbo.brand b left join dbo.vendor v ....).

Hope this helps.