Mike Hadlow’s blog has a great writeup on using Castle Windsor with WCF.
http://mikehadlow.blogspot.com/2008/11/windsor-wcf-integration.html
Also included is information on using WCF with Windsor/NHibernate:
http://mikehadlow.blogspot.com/2009/02/wcf-windsor-integration-using.html
I followed his advice, pulled down his sample code, and was quickly able to implement in my WCF services. Thanks Mike!
Castle Windsor is my ‘favorite’ IOC – as it offers quite a bit of functionality, and it’s fairly easy to understand and setup. Let’s review how to programmatically add components to the container.
By default the registration of components is all done via xml configuration files. However, Castle Windsor does support programmatic registration of components to the container. Why would you do this? Well, one example is where I register components in ‘one fell swoop’ that exist in an assembly, making it completely hands off when adding a new component. Due to the autowiring nature of Windsor, most of the work is done by the container. Let’s look at an example:
ie. I have an assembly with my ‘services’ and assembly with my ‘dao’s’.
The flow is: My controller uses ‘service(s)’. My services uses dao(s).
Controller => Service Layer => Dao/Repository Layer
I’ll pseudo code this:
//The controller
public class EmployeeController
{
private readly IEmployeeService EmployeeService;
public EmployeeController(IEmployeeService EmployeeService)
{
this.EmployeeService = EmployeeService;
}
public ActionResult SaveEmployee(string id)
{
Employee employee = EmployeeService.GetEmployeeById(id);
employee.FirstName = ….
EmployeeService.SaveEmployee(employee);
return ….
}
}
//The Service:
public class EmployeeService : IEmployeeService
{
private readly IEmployeeDao EmployeeDao;
public EmployeeService(IEmployeeDao EmployeeDao)
{
this.EmployeeDao= EmployeeDao;
}
public void SaveEmployee(Employee employee)
{
using(ITransaction trans = …BeginTransaction())
{
EmployeeDao.Save(employee);
trans.Commit();
…
}
}
}
//The Dao:
public class EmployeeDao : Dao<T>
{
…. Save(T entity)…
}
So we have our tiered environment, the controller passes off the employee object ‘stuff’ to the service. The service handles the transactional aspects, etc… and calls the underlying Dao database calls. The beauty here, it’s all constructor injection, no ‘new object’ etc…
So, along comes Castle Windsor. If you noticed, I’m using a controller with action result – that is from asp.net mvc. The MvcContrib contains code to register the controllers with the container, which can be accomplished in three lines of code in the startup of the application (Global.cs):
IWindsorContainer _container = new WindsorContainer();
ControllerBuilder.Current.SetControllerFactory(new WindsorControllerFactory(_container));
_container.RegisterControllers(Assembly.Load("Bistro.Controllers"));
After that we can register the services and daos:
ie.
_container.Register(
AllTypes.Pick().FromAssemblyNamed("Services")
.Configure(c => c.LifeStyle.Transient)
.If(s => s.Name.Contains("Service"))
.WithService.FirstInterface()
);
This fluent interface sample will look at each type in the Service assembly, were name contains ‘service’, and then add the interface. (This does require a bit of naming convention on my part, ie. EmployeeService : IEmployeeService – ‘service’ in the name, however, I do like that if I want to exclude something it can be done quite easily)
The registration of the dao is similiar to above.
_container.Register(
AllTypes.Pick().FromAssemblyNamed("Dao")
.Configure(c => c.LifeStyle.Transient)
.If(s => s.Name.Contains("Dao"))
.WithService.FirstInterface()
);
So, I’ve registered all the controllers, all the services, and all the daos. They are autowired by Windsor, meaning, I don’t have to hand by hand register each type with instructions on who uses what – it uses reflection to handle that – seeing for example, that I have a IEmployeeService being injected – so look for that type in the container and create a new one on my behalf.
The last example is : what about the facilities ? ie. Castle Windsor has great support for EventWiring:
http://www.castleproject.org/container/facilities/trunk/eventwiring/index.html
And a great sample by Hammett:
http://hammett.castleproject.org/?p=115
The beauty of this is that you can register your subscribers in the container! I think it’s fanatastic
We’ll take a similiar example to what Hammett uses.
ie. in my sample (read Hammett’s blog), WITHOUT Windsor, we’d have to code up all the registrations, etc…:
INotificationService notification = new DefaultNotificationService();
//subscribers
SuccessSubscriber subscriber1 = new SuccessSubscriber();
FailedSubscriber subscriber2 = new FailedSubscriber();
//subscribing
notification.Succeeded += new NotificationHandler(subscriber1.OnSuccess);
notification.Failed += new ErrorNotificationHandler(subscriber2.OnFailure);
TheService service = new TheService(notification);
//use the app:
service.DoService();
Let’s see what is would be like with Castle Windsor and a configuration file:
Here is my config fi
le that we will convert to the fluent registration:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section
name="castle"
type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />
</configSections>
<castle>
<facilities>
<facility id="event.wiring"
type="Castle.Facilities.EventWiring.EventWiringFacility, Castle.MicroKernel" />
</facilities>
<components>
<!– Subscribers –>
<component id="SuccessSubscriber"
type="MyEventSample.SuccessSubscriber, MyEventSample" />
<component id="FailedSubscriber"
type="MyEventSample.FailedSubscriber, MyEventSample" />
<!– Notification service –>
<component id="notification.service"
service="MyEventSample.INotificationService, MyEventSample"
type="MyEventSample.DefaultNotificationService, MyEventSample" >
<subscribers>
<subscriber id="SuccessSubscriber"
event="Succeeded"
handler="OnSuccess"/>
<subscriber id="FailedSubscriber"
event="Failed"
handler="OnFailure"/>
</subscribers>
</component>
<!– Services –>
<component id="TheService"
type="MyEventSample.TheService, MyEventSample" />
</components>
</castle>
</configuration>
So, we tell Castle about the facility. We add our components that are being used. Then we add our subscribers in the notification service:
WindsorContainer container = new WindsorContainer(new XmlInterpreter(new ConfigResource()));
TheService service = container.Resolve<TheService>();
service.DoService();
That is excellent – in 3 lines of code, we have all our subscribers wired up, etc… In this example, we are telling the container to read the configuration file above.
But what if, we want to dynamically register these components, without the xml (the point of the blog post – lol) ?
We do so using the fluent interfaces – with special attention given to ‘how to register a facility’:
Here is the code:
IWindsorContainer container = new WindsorContainer();
container.AddFacility<EventWiringFacility>();
container.AddComponent<SuccessSubscriber>("SuccessSubscriber");
container.AddComponent<FailedSubscriber>("FailedSubscriber");
container.AddComponent<TheService>("TheService");
container.Register(Component.For<INotificationService>()
.ImplementedBy<DefaultNotificationService>()
.Configuration(Child.ForName("subscribers")
.Eq(
Child.ForName("subscriber").Eq(
Attrib.ForName("id").Eq("SuccessSubscriber"),
Attrib.ForName("event").Eq("Succeeded"),
&#
160; Attrib.ForName("handler").Eq("OnSuccess")
),
Child.ForName("subscriber").Eq(
Attrib.ForName("id").Eq("FailedSubscriber"),
Attrib.ForName("event").Eq("Failed"),
Attrib.ForName("handler").Eq("OnFailure")
)
)
)
);
Then it is used the same way as above:
TheService service = container.Resolve<TheService>();
service.DoService();
With some imagination, you can see how easy it would be to register all subscribers in an assembly, all services in a assembly, then wire them all up dynamically.
(To see how I did the facility you can look at this test)
So in summary, you can add items to the config, and read it. Or you can dynamically add them in code. It is possible as well to mix the two. I initially did this, where I load the config with the subscriber information, then add in my components programmatically.
I hope this helps, if anyone would like some sample code to go along with this, I can provide it – just let me know.
Unfortunately, there is no wiki documentation, etc… on the Castle Binders in the MvcContrib. So I thought I’d hop in and write up a sample for anyone else interested in using these binders:
First, for some background information from the Castle website : http://www.castleproject.org/monorail/documentation/trunk/usersguide/smartcontroller.html
These binders were originally created for Monorail, and outside of a few items, most of that documentation applies to using with MvcContrib.
I’m using the latest MvcContrib from the trunk (SVN) at :
http://mvccontrib.googlecode.com/svn/trunk
After building the MvcContrib, there assemblies referenced are from:
trunksrcMvcContrib.CastlebinRelease (I just added them all to a new Mvc project)
(I’ll include the source here if you just want to download and try it)
The goal of the binders is to provide the ability to include a strongly typed object as the recipient to a form post to an action. As described in the document above, the default would be:
ie.
Person person = new Person();
person.FirstName = Request.Form[“FirstNameâ€];
Step One: Create Controller implementing the ICastleBindingContainer interface
Step Two : Create Actions to handle the Form post
(note: the HttpVerbs allow you to specify one named Action – for different uses: the Get is for the form load, the Post is for the form post)
The post action of BindersView takes a ‘Person’ object. We use the ‘CastleBind’ attribute to specify the binding.
There are a few optional parameters with the CastleBind: The prefix to use, and the Exclude option.
This allows you to specify a prefix of any name in the form itself (I show form next). The exclude allows for properties to not be included in the post request.
(For example, if you have a sensitive property of Person, ie. social security – you can exclude it from the binding)
Step Three : The Model
Step Four : The Form
Let’s show the form now:
The first form fields represent the ‘Person’, and I’m also including form fields for the spouse to be added.
Note the ‘person.FirstName’ – the prefix is required. Also, the Spouse object is referenced as ‘person.Spouse.FirstName’. This will help instruct how to bind to the object.
(You can read more about this in the Castle documention link above)
Let’s run it:
On save:
As you can see – it has bound to the person object as expected.
I hope this helps show, in a simple example, how to use the Castle Binders in MvcContrib.
