Issue
I am using Castle Windsor as an IoC container in a Castle Monorail project. I would like to inject the current instance of IRailsEngineContext into an object being resolved from the container in a controller.
Context
The object I would like inject the rails context into would be used to wrap the session object for the purpose of retaining the ids of previously viewed records. It would then be referenced to ensure that they aren't viewed again.
Alternate Solutions
I could pass the context to the methods with each call or inject it manually, but it would be nice to inject it directly from the container.
Question
I can't think of a way to inject the context within the container. Is there a way to do this? Does this even make sense?
Container.Register(
Component.For<IRailsEngineContext>()
.UsingFactoryMethod(()=>MonoRailHttpHandler.CurrentContext)
.LifeStyle.Transient
);
IRailsEngineContext - that's from an old version of MonoRail I guess. I'd advise you move to a newer one, the sooner the better.
Related
I am a newcomer to C# / .Net / Prism / WPF / DevExpress and started to work on a big project in my company. As I am starting a bit late in the project, a lot of code was already produced and I stumble upon code like this very often:
public class AboutWindowViewModel : BindableBase
{
public AboutWindowViewModel(IUnityContainer container)
{
...
What I find "special" here is the dependence of the view model in the container. In the codebase I am currently looking at, it seems to be the "pattern". Every class gets a dependence in the IUnityContainer and then the dependencies are resolved manually with e.g.
container.ResolveEx<...>(...);
I am used to work with DI frameworks in other languages, so that example was just a non-sense to me because it goes against the definition of a DI framework and the problems it is meant to solve. For example, I tried to make up some code to test one of those view models and it turned out to be a nightmare.
Now, I addressed that concern to the developpers of my company and they answered me the following:
Prism recommendation is to resolve services using containers as they are needed.
Therefore, they resolve them all the time with the IUnityContainer.ResolveEx method.
My question is: is that really the recommended way to build up software with Prism??? If not, do you know where I can find documentation that clearly addresses that point with examples?
is that really the recommended way to build up software with Prism???
Not at all, in it's an anti-pattern.
Prism recommendation is to resolve services using containers as they are needed.
Not really just Prism, but more generally, the recommendation is to let the container resolve the dependencies. Of course, this can be done by calling Resolve manually, but in doing that one defeats all the benefits expected from dependency injection.
Rather, you want to list the dependencies as constructor parameters and let the container fill them. Your code does not need to depend on the container, except for the very entry-point ("resolution root"). The application should only ever contain a single Resolve statement that resolves the first instance.
Here's where Prism comes into play: in your PrismApplication.RegisterTypes and IModule.RegisterTypes, you configure your container. You tell it which type should implement which interface. Later on, when view models are needed, Prism (the ViewModelLocator to be precise) uses the container to resolve the view models, thereby resolving all the dependencies. There's no reason to make any class depend on the container, in fact, Prism doesn't register anything for IContainerRegistry in the first place.
Keep in mind that the container can not only inject singleton services, but also transient instances or factories. And if you need parametrized factories, you can always manually create and register complex factories.
On a side-note, I, personally, would be hesitant to work for a client with a code-base like this, as it's an obvious proof that their developers have no idea what they're doing.
I would like to know in best practice questions and think of easily testable classes, when I need multiple different instances of the same (fabricated) object within a specific class, which approach is recommended?
Before I used the Service Manager build method, but it is no longer recommended to inject Service Manager directly into a class, right?
I'm new here and hope my first question does not confuse anyone.
I am using Castle Windsor and Castle DynamicProxy together, in order to integrate AOP with IOC, so that I can implement a logging service (and auditing, etc.) with will intercept all services in my project.
I'm trying to proxy the resolved instance to get this done but with no luck. Because the proxy returned will have the properties of the resolved instance set to null. Following is the debugging info for reference (the PROBLEMATIC property is TimeService).
the resolved instance before proxied
The resolved instance before proxied.
the proxied object
The proxied object
Did I miss something or did i understand Castle DynamicProxy in a wrong way? I did search for any solutions but had no luck.
Any answers is highly appreciated. Thanks in advance.
You should use Windsor's built-in support for AOP during registration, not overriding WindsorContainer.Resolve otherwise you'll also run into other problems around releasing components and container lifetimes:
container.Register(
Component.For<ICalcService>()
.Interceptors(InterceptorReference.ForType<ReturnDefaultInterceptor>()).Last,
Component.For<ReturnDefaultInterceptor>()
);
See the docs for more info: https://github.com/castleproject/Windsor/blob/master/docs/registering-interceptors-and-proxyoptions.md
Basically, should I call .Dispose() myself? Because from what I've read, Windsor won't do that for me. I'm new to IoC and this is slightly confusing.
Have a look to KK mvc3 tutorial.
WindsorControllerFactory acts as composition root: factory takes care to create and release controller via container. Since "Windsor is best of breed, mature Inversion of Control container available for .NET" takes care to release all components starting from the root of the object graph... as long as you properly set up the container...
Read also this post about windosr releasing policy.
I am migrating to ASP.NET MVC 3.
Now I have some ways of resolve controller with IoC.
My controller need a contructor injection parameter for repositories.
Setting DependencyResolver.SetResolver works. But I don´t know if this is correct way or I need to Register a IControllerActivator at my container too.
What you need is a ControllerFactory.Most IOC containers have an existing implementation. If you need a custom one, check this article:
http://develoq.net/blog/?p=144
Update
It's the correct way. DependencyResolver is generic for everything, and you need to register the IControllerActivator in it.
http://bradwilson.typepad.com/blog/2010/10/service-location-pt10-controller-activator.html