As part of prepar­ing for release of Wind­sor 3.1 I decided to revisit parts of Windsor’s doc­u­men­ta­tion and try to make it more approach­able to some com­pletely new to IoC. This and few fol­low­ing posts are excerpts from that new doc­u­men­ta­tion. As such I would appre­ci­ate any feed­back, espe­cially around how clearly the con­cepts in ques­tion are explained for some­one who had no prior expo­sure to them.

As every tech­nol­ogy, Wind­sor has cer­tain basic con­cepts that you need to under­stand in order to be able to prop­erly use it. Fear not — they may have scary and com­pli­cated names and abstract def­i­n­i­tions but they are quite sim­ple to grasp.

Ser­vice

First con­cept that you'll see over and over in the doc­u­men­ta­tion and in Windsor's API is ser­vice. Actual def­i­n­i­tion goes some­what like this: "ser­vice is an abstract con­tract describ­ing some cohe­sive unit of functionality".

Ser­vice in Wind­sor and WCF ser­vice
The term ser­vice is extremely over­loaded and has become even more so in recent years. Ser­vices as used in this doc­u­men­ta­tion are a broader term than for exam­ple WCF services.

Now in plain lan­guage, let's imag­ine you enter a cof­fee shop you've never been to. You talk to the barista, order your cof­fee, pay, wait and enjoy your cup of per­fect Cap­puc­cino. Now, let's look at the inter­ac­tions you went through:

• spec­ify the cof­fee you want
• pay
• get the coffee

They are the same for pretty much every cof­fee shop on the planet. They are the cof­fee shop ser­vice. Does it start mak­ing a bit more sense now? The cof­fee shop has clearly defined, cohe­sive func­tion­al­ity it exposes — it makes cof­fee. The con­tract is pretty abstract and high level. It doesn't con­cern itself with "imple­men­ta­tion details"; what sort of coffee-machine and beans does the cof­fee shop have, how big it is, and what's the name of the barista, and color of her shirt. You, as a user don't care about those things, you only care about get­ting your cap­puc­cino, so all the things that don't directly impact you get­ting your cof­fee do not belong as part of the service.

Hope­fully you're get­ting a bet­ter pic­ture of what it's all about, and what makes a good ser­vice. Now back in .NET land we might define a cof­fee shop as an inter­face (since inter­faces are by def­i­n­i­tion abstract and have no imple­men­ta­tion details you'll often find that your ser­vices will be defined as interfaces).

public interface ICoffeeShop
{
   Coffee GetCoffee(CoffeeRequest request);
}

The actual details obvi­ously can vary, but it has all the impor­tant aspects. The ser­vice defined by our ICof­feeShop is high level. It defines all the aspects required to suc­cess­fully order a cof­fee, and yet it doesn't leak any details on who, how or where pre­pares the coffee.

If cof­fee is not your thing, you can find exam­ples of good con­tracts in many areas of your code­base. ICon­troller in ASP.NET MVC, which defines all the details required by ASP.NET MVC frame­work to suc­cess­fully plug your con­troller into its pro­cess­ing pipeline, yet gives you all the flex­i­bil­ity you need to imple­ment the con­troller, whether you're build­ing a social net­work­ing site, or e-commerce application.

If that's all clear and sim­ple now, let's move to the next impor­tant con­cept (in the next post).