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.

Com­po­nent

Com­po­nent is related to ser­vice. Ser­vice is an abstract term and we're deal­ing with con­crete, real world. A cof­fee shop as a con­cept won't make your cof­fee. For that you need an actual cof­fee shop that puts that con­cept in action. In C# terms this usu­ally means a class imple­ment­ing the ser­vice will be involved.

public class Starbucks: ICoffeeShop
{
   public Coffee GetCoffee(CoffeeRequest request)
   {
      // some implementation
   }
}

So far so good. Now the impor­tant thing to remem­ber is that, just as there can be more than one cof­fee shop in town, there can be mul­ti­ple com­po­nents, imple­mented by mul­ti­ple classes in your appli­ca­tion (a Star­bucks, and a CofeeClub for example).

It doesn't end there! If there can be more than one Star­bucks in town, there can also be more than one com­po­nent backed by the same class. If you've used NHiber­nate, in an appli­ca­tion access­ing mul­ti­ple data­bases, you prob­a­bly had two ses­sion fac­to­ries, one for each data­base. They are both imple­mented by the same class, they both expose the same ser­vice, yet they are two sep­a­rate com­po­nents (hav­ing dif­fer­ent con­nec­tion strings, they map dif­fer­ent classes, or poten­tially one is talk­ing to Ora­cle while the other to SQL Server).

It doesn't end there (still)! Who said that your local French cof­fee shop can only sell cof­fee? How about a pas­try or fresh baguette to go with the cof­fee? Just like in real life a cof­fee shop can serve other pur­poses a sin­gle com­po­nent can expose mul­ti­ple services.

One more thing before we move for­ward. While not implic­itly stated so far it's prob­a­bly obvi­ous to you by now that a com­po­nent pro­vides a ser­vice (or a few). As such all the classes in your appli­ca­tion that do not really pro­vide any ser­vices will not end up as com­po­nents in your con­tainer. Domain model classes, DTOs are just a few exam­ples of things you will not put in a container.