Codes can be downloaded here.
The proven viability of Aspect Oriented Programming (AOP) as a programming paradigm has led to the porting of popular Inversion of Control frameworks to multiple platforms. One of these frameworks is the Castle Windsor which has its roots in open source and Java communities. One of the tenets of AOP is to promote loose coupling among the different components of your application so that anytime during application’s lifetime, the implementations of the functionalities can be changed without affecting the codes. Changes would involve only adding of entries in a configuration file. In this entry, I will show the most common and the fastest way of initializing Castle Windsor. Figure 1 illustrates the different components of a typical application adhering to AOP. The context, which is the final application, uses only abstraction objects in the form of interface. The implementations of the abstraction, known as concretes, are in separate components and are developed independently. The role of Castle Windsor is to “inject” the desired concrete during runtime. In so doing, the context will also create an association to the concrete but since this activity is dynamic, the diagram does not show it. Which concrete to inject is determined from an entry in the configuration file.
Fig. 1 - Component diagram of the sample solution
The code below shows a very simplistic interface which will be abstracting the application from the concrete implementations.
Fig. 2 - The abstraction interface
The implementation is likewise simplistic. All we need is an indication of what assembly is being injected.
Fig. 3 - Sample implementation of the abstraction
In order for Castle Windsor to inject a particular concrete assembly, that assembly has to be referenced by the application together with its dependency stack. Figure 4 shows all the concretes being referenced but this is not always the case. You just need to reference what you intend to inject.
Fig. 4 - Required assemblies in the final application
Castle Windsor needs a customized section in the configuration file and the list of concretes you want to inject, each identified by a string ID. Each item in the list is defined by the <component> node. Besides the ID, the node also specifies the full type name and the assembly of the abstraction and the concrete. The code will retrieve these data during runtime using the ID as you’ll see in the next section.
Fig. 5 - Configuration entries for Castle Windsor
The first thing to do in the application codes is to initialize the IoC container. Figure 6 shows instantiation of the container using an overload that reads the “castle” section in the configuration file. The container is responsible for resolving the correct type based on the entry in the configuration which is illustrated in the next line.
Fig. 6 – Code usage
Since we’re specifying ExtensiveSearcher as our searcher, we get the result in Figure 6. Swapping the entries would affect the display accordingly.
