I'm still learning Castle Windsor and I see that it supports forwarded types - a term I was unfamiliar with.
Quick Google search and I found this article that explains it pretty throughly however I still don't understand how this applies to IoC or how I would use them from a container and for what reason.
Can anyone explain?
Type forwarding is a way to move type from one assembly to another without introducing breaking changes it has nothing to do with IoC. So you should not worry about this feature :)
Oh man, just did a google search on 'Castle Windsor "Forwarded Types"' and got redirected right back to SO:
Using Castle Windsor configuration files is it possible to delegate to another item declaration?
and from there:
What are “ForwardedTypes” in the context of Castle Windsor component registration?
Maybe Jeff and the team should just give up on trying to have their own search and use google's.
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'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
Previously I asked this question and on a answer I got this comment:
This works, however injecting the container to a part, as far as I know, is not a "normal" use-case of MEF.
In my web app I have a few repositories that, of course, retrieve entities from the DB. To make them as loosely coupled as possible I'm making them return interfaces (eg IUser, IBill, IBlaBlaBla...) and the repository project only references the library project (that contains the interfaces). I use MEF composition capabilities to tie it all up...
Since the repository must have a concrete object to fill with info it got from the DB and the only the Container is aware of which concrete class maps to a specific interface I think that the repository MUST have reference to the container so it can call the "Resolve()", get a new instance and do his job, but that apparently is a mistake.
Can anyone tell me why and what approach would be better?
PS: I don't know if it's relevant but I'm using DDD...
I think the flaw in your design that lead to this problem is the use of interfaces to hide entities behind. Since entities are your core concept in your domain, there should be no use in hiding them behind an abstraction. Let's put it differently: do you ever have a different implementation of IUser?
In other words, ditch the IUser, IBill, etc. interface and let your repositories and business commands depend directly on your aggregate entities.
I have the following bit of registration code:
Component.For<IPublishingService>().ImplementedBy<UseStoredProcedureToPrintService>(),
Component.For<IConfirmationDialog<AutomatedTransaction>>().ImplementedBy<ShipmentConfirmationDialog>().Named("ShipmentConfirmationDialog"),
Component.For<IConfirmationService<AutomatedTransaction>>().ImplementedBy<SingleTransactionConfirmation>().ServiceOverrides(
ServiceOverride.ForKey("shipmentDialog").Eq("ShipmentConfirmationDialog") ),
A requirement came down the line that in some instances the application is supposed to behave somewhat differently. Great I thought, this is exactly what I was using Castle Windsor for to begin with.
So I wrote my new components and I register them first. For example, I implement IPublishingService differently and register the new implementation first so that it is resolved over the default one above. However, a problem occurrs in the few cases where I had no choice but to use an id to wire up my service overrides. For example how do I redirect the ServiceOverride for ShipmentConfirmationDialog to use my new SpecialCaseShipmentConfirmationDialog implementation without modifying the bit of code above?
There are all sorts of mechanisms in castle windsor that I don't really understand like forwarding and ActAs that I'm hoping will provide a simple answer.
I'd keep it simple. If it's configurable, put it in the config (web.config / app.config) then just load the ID using ConfigurationManager.AppSettings["shipmentDialogToUse"];
Also remember that the fluent registration API is not the be-all and end-all of registration. XML still has its time and place where it's the right tool for the job.
Is the provider pattern an implementation of IOC? If not, why not?
(reading through martin fowlers article on ioc)
In my opinion, yes the Provider pattern is a form of Inversion of Control.
What's my reasoning?
At it's core IoC is a very generic concept, so much so that Martin Fowler talks about reading user input from the command line as being a form of IoC.
With the Provider model the inversion happens when the provider framework decides which provider will be used when a given method is called. For example when you invoke Membership.GetUser your code is delegating control of which Membership provider to use, to the provider framework.
As Fowler says "Inversion of Control is a common characteristic of frameworks" and if you think about it many patterns are concerned with IoC (e.g Strategy pattern). I would go as far as to say that even polymophism is a form of IoC (a point I would happily like to hear a counter argument to).
Spring uses BeanFactory and its concrete implementations, most important of which is ApplicationContext. Don't know what Guice does.
I think even if it is, you shouldn't necessarily use it "instead of" IOC or you will be missing out and have a messy code base. IOC containers can generally be configured in code which can be more powerful and far easier to maintain, whereas the Provider Model must be configured in the Web.Config.
I am actually considering moving away from the Provider Model now that I am using an IOC container because it seems like overkill.
Read more on my blog post - hopefully the blog will get some good comments about it too:
http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html