I’ll be talking about fluent nHibernate in the near feature. Fluent nHibernate is a great new open source framework, that will allow us to create our mappings in code (means no XML!) using a fluent API.

More about fluent nHibernate later. The goal of this post is to bring some more light into the dark when talking about fluent interfaces as fluent nHibernate uses this style.

It’s been a while since this term is around, just notice the date this article was written… But to be honest, I didn’t actually know the term until I ran into fluent nHibernate myself!

Fluent interfaces… Come again?

Fluent interfaces are not a very common style, but it sure is very nice to work with.

Imagine baking a pizza (that’s what I’m eating right now :p ):

Pizza myFluentPizza = Pizza.Create()

instead of how we do it now:

Pizza pizza = new Pizza();
pizza.Size  = PizzaSize.Medium;
pizza.BorderFilling = PizzaFilling.Cheese;
Topping tunaTopping = new Topping("Tuna");
Topping onionsTopping = new Topping("Onions");
Topping mozarellaTopping = new Topping("Mozarella");

Just notice the complexity of the code we write normally to achieve this. It makes you create all the toppings yourself, while when using the fluent interface, the Pizza worries about creating the topping, you just worry (if that’s even worrying at all) adding it to your pizza, thus wiring it up.

There’s a lot less noise in the code, just with a very quick look you immediately know what kind of pizza you’re baking here.

How did you…?

Well actually, I’m sure you’ll think “d’oh” when you see it, it’s quite simple:

public class Pizza
   public PizzaSize Size { get; private set; }
   public PizzaFilling Filling { get; private set; }
   public IList<Topping> Toppings { get; private set; }

   public static Pizza Create()
      Pizza pizza = new Pizza { Toppings = new List<Topping>() };
      return pizza;

   public Pizza OfSize(PizzaSize size)
      Size = size;
      return this;

   public Pizza WithBorderFilling(PizzaFilling filling)
      Filling = filling;
      return this;

   public Pizza WithTopping(string topping)
      Toppings.Add(new Topping(topping));
      return this;

   public Pizza Bake()
      // bake the pizza somehow
      return this;

I’ll spare you the enums and the Topping class, since it just contains a constructor accepting a string parameter…

Notice the only method that’s not returning the Pizza instance is the Bake method. I did this so you can’t directly call the other methods anymore. Once a pizza is baked, it’s a bit useless to add more toppings or adjust the border filling, don’t you think? Baking the pizza, is in this case the end of the chain.

Simpler than you thought, isn’t it?

Method chaining

I mentioned that the Bake() method above, was the end of the chain for this example. End of what chain? Well, when implementing a fluent interface, you’ll notice you’re using a lot of method chaining.

First let me give you an example of method chaining we can find in the .NET framework to clarify what it actually is:

StringBuilder builder = new StringBuilder();
builder.Append("Did you ")
       .Append("like my ")

string test = "Hello, I'm here to clarify method chaining";
test.Substring(1, 7)

Don’t tell me you’ve never used this syntax before? It makes your code very straightforward and easy to read.

How this works is very simple:
Just make your method return the object you’re calling the method on, and there you go! It also gives a different implementation if you’re using it on your properties (no automatic setters anymore!), but it’s very straightforward.


Fluent interfaces introduce a new style of coding, one that’s more readable and to-the-point. It does acquire some more coding, but in some cases, offering a fluent interface just is more important than spending more time on development.

Expect some posts about fluent nHibernate in the near future!