A little background relevant to my problem:- I'm learning to use SignalR, which is a client-server RPC framework. On the server-side you write one or more "hub" classes which expose methods that can be called remotely, a bit like a web service. When a message arrives, SignalR instantiates the appropriate hub class to handle that message, but for this to work hub classes must have a parameterless constructor.
In the real world, a hub class is likely to need dependencies. Fortunately SignalR lets you replace its default "dependency resolver", which I've done. There are numerous (almost identical) samples of SignalR Castle Windsor resolvers (e.g. here), but they all rely on calling the Windsor container's Resolve() method. My understanding of Windsor is that you must "release what you explicitly resolve", but I can't see where I could achieve this.
Note that the hubs are registered as transients, while dependencies may be a mixture of transients and singletons.
I thought about releasing a hub's dependencies in its Dispose() method, but this feels wrong - the hub would need access to the Windsor container; also the hub needs to know which dependencies are transient, and only attempt to release those.
Any thoughts?
IMHO you are bitten by the fact that the signal R dependency resolver fails to implement a Destroy method for releasing the hubs.
I agree that implementing the release of the components in the Hub's dispose method would get rather ugly. To release the hub from windsor the hub would need to call release on the container which in turn would then call the dispose again on the hub.
I think you're best bet would be to create an windsor interceptor for the hub, which will intercept the dispose call on the hub. This way only the interceptor needs to know about the container and you should be able to dispose you component.
You might need some logic in your interceptor to determine whether dispose is called from SignalR or from then windsor container. (ie if called from SignalR call Windsor release, otherwise proceed). You might do this by using e.g Thread local storage.
Related
container.Register(
Component.For<IMyService>()
);
This code intent to register a service IMyService in Windsor container,but i didn't found any significance use of doing that. am i am missing something here or it is just a syntax practicing?
It depends.
In this case, since your service is an interface it's most likely not terribly useful with default configuration, because you won't be able to instantiate that component most likely.
I'm saying most likely, because you didn't show the definition of the interface, nor the code that configures your container (more on that in a moment).
If your service was a class, it would be a usable registration.
Now the more advanced stuff. In advanced scenarios you can have extensions augmenting your registration, by using custom IContributeComponentModelConstruction, or component model attributes (like InterceptorAttribute) which could extend this simple registration to something more complete.
I'm about to embark on a new project using Windsor, but I've been wondering about running into scenarios where a Class A might need to instantiate Class B, but it's not feasible or possible for Windsor to inject an instance of Class B into it. I'm struggling to think of a scenario, but here goes:
Say I have a business entity "Customer" that gets passed to a WCF service. This class has an Ent.Lib self-validation method, which in turn uses a helper class "CustomerValidator". The Customer object received by the service has been deserialized by WCF, so Windsor plays no part in its instantiation, so I can't inject any dependencies. Nor can I pass my CustomerValidator to the self-validation method as it must follow a particular signature for Ent.Lib. So how could I instantiate the CustomerValidator within this class/method? I still want to utilise Windsor rather than simply doing a "var cv = new CustomerValidator();".
It's not a great example as it could be solved in different ways, e.g. passing the Customer object to a validation method rather than having the validation method in the Customer class, but it offers a possible scenario for discussion.
I could expose my WindsorContainer as a public singleton, accessible by any code that needs it, but that seems to be frowned upon. Any other suggestions?
should I reference the container from other classes?
No. By referencing the container, you add complicated and unnecessary dependency to your class which will complicate testing and increase complexity.
The Customer object received by the service has been deserialized by WCF, so Windsor plays no part in its instantiation, so I can't inject any dependencies.
I think this is the direction you should go, try to explore if there really isn't any way to take control of deserialization so you can inject dependencies.
If that fails, consider using http://commonservicelocator.codeplex.com/. Its Microsoft's service location implementation with Windsor adapter available. It's basically the same pattern as if you referenced the container but you don't introduce dependency on specific container implementation. Also I think it will be easier to mock for testing.
I am developing an AS3 application which uses a Singleton class to store Metrics in Arrays. It's a Singleton because I only ever want one instance of this class to be created and it needs to be created from any part of the app.
The difficulty comes when I want to unit test this class. I thought adding public getters and setters would enable me to unit test this properly and would be useful for my app. I have read that changing to a Factory pattern will enable unit testing or using Inversion of control. This would of course make it more flexible too. I would like to know of people's thoughts on this matter as there are SO many conflicting opinions on this!
Thanks
Chris
If you're using an IoC framework, then make your consumers require an instance of the service in their constructor, and configure the IoC framework to only build one instance and keep handing it out to all requests in the entire application. This is the default behavior of Castle Windsor in my experience.
For unit testing you can use a Mock object in place of the real object.
When I started with Windsor I thought DI would be simple. Now it's causing me more and more confusion.
A repository strikes me as a class with a singleton lifecycle. I should have a single instance of a FooRepository to load and save Foos to the database during the application's lifetime.
However, each repository holds a reference to a UnitOfWork, which does the dirty checking, works with the database etc. The UnitOfWork has a lifecycle of PerWebRequest - it makes no sense at all for the UnitOfWork to be a singleton, as a singleton instance could (for example) flush the changes made by several user sessions at the same time.
So then I have a singleton FooRepository holding a reference to a UnitOfWork, which at the end of the session gets disposed! I'm not even sure what effect that would have on the repository's behaviour, but it doesn't sound good.
Can anyone explain, in simple English (okay, maybe with some code), the appropriate way to manage the lifecycle of Repository and UnitOfWork classes in a web app?
Rule of thumb is - component should not depend on other components that will outlive it.
In other words, it's ok for transient to depend on singleton, or per-web-request component, but not the other way around.
The way I approach Repository - UoW scenario is my UoW is per web request, but repositories are stateless and transient.
When you say repository, I assume you mean a repository which abstracts an Nhibernate session.
If so, then it should never ever be singleton. If it is a singleton, then multiple request threads will trample over one another's session. I personally have seen a few defects around this. Since Castle's default life cycle is singleton, if a developer forgets to explicitly mark a component's life cycle, bad things start happening.
It should ideally be per-request (following the unit of work concept). The only rider to this approach is that you have enable Asp.net compatibility mode in your application (if it's not Asp.net that is). The other way is to mark a repository transient. But the downside to this approach is that Castle will instantiate a new repository object every time a component needs it.
I would like to have Windsor inject multiple implementations of a service to a constructor.
My scenario is that I have multiple search providers that implement a common interface. I would like to register each of these with windsor and then inject them into my search service so it can query each on in turn.
Is such a thing possible with Windsor? Is there a better approach than injecting multiple implementations into the constructor?
See Inversion of Control and Dependency Injection with Castle Windsor Container - Part II at DotNetSlackers. It shows how to pass an array of the same service interface to an object.