Customer Contact Manager is a simple sample application showcasing usage of Castle Windsor in Silverlight. This page will walk you through all the features of Windsor used by the application. You can download the code here.
The application uses Silverlight 4 and Windsor 2.5. If you want to download the entire source code, it uses Visual Studio 2010 solution.
Bootstrapping - the guywire
The application uses a dedicated class, called
to implement the Three Container calls pattern
. It does so via the following three methods:
To read more about the guywire pattern see this
Container set up - installers
Installers folder in the solution
The application uses Windsor Installers
to encapsulate code responsible for registering components with the container. Each group of the components has dedicated installer type. All installers are contained in a dedicated project folder/namespace to cleanly separate them from the rest of the application.
For demonstration purposes each installer uses different pieces of API available to register the components.
Behaviors in the application are classes extending our model with additional capabilities. They are implemented as DynamicProxy Interceptors
Command installer installs commands which handle interactions with the user. Commands use attributed registration
.Where(t => t.Namespace.EndsWith("Commands") &&
Model Installer registers model objects in our application (due to extreme simplicity of the app there's just one such class -
.Configure(c => c.LifeStyle.Transient
.ConfigureFor<Customer>(c => c.DynamicParameters(
(k, @params) => @params.Insert(DateTime.Now))));
That's the most complicated installer in the application and there's quite a lot of stuff happening here so let's go over each step in turn
- line 3 - In addition to filtering (selecting which types to register and relying on defaults like in previous installers) we explicitly specify a non-default lifestyle.
- line 4 and 5 - Additionally we specify two interfaces we want our model objects to implement -
INotifyPropertyChanged. These are Silverlight interfaces that will give our model objects editability and notifications to/from the UI of changes property values.
- line 6 and 7 - To provide implementation for the interfaces we specify interceptors that will handle the task.
- lines 8 and 9 - in addition to above configuration that will be applied to all components matched by the filtering conditions, we specify additional fine-grained configuration just for
Customer class - we specify typed Dynamic parameter for
DateTime (we'll discuss why we do that when we cover
Service installer registers application services. We have three of these -
delegate which is registered implicitly.
.Eq("Fake service Uri for fake repository, but you get the idea")),
We register Typed Factory Facility
, so that we can use
delegate as typed factories (interface-based
In addition we register static named dependency
for customer repository - serviceUri. In real application that would be address of our backend service. In .NET app we could pass connection string like this.
View installer registers views in our application based on namespace