I have been looking into the Castle project and specifically Windsor. I have been so impressed with what is possible with this technology and the benefits of having a such a loosely coupled system are definitely apparent. The only thing I am unsure of is if using this method has any downsides, specifically in asp.net? for example performance hits, etc.
I am trying to make the benefits of this approach visible to my fellow developers here and am being hit with the following comebacks:
That is using reflection and each time that an object is called from the container, reflection must used so performance will be terrible. (Is this the case? does it use reflection on every call?)
If I am relying on Interfaces; how do I deal with objects that have extra methods and properties which have been tacked onto the class? (through inheritance)
Castle Windsor is Dependency Injection container. It means with the help of this you can inject your dependencies and use them without creating them with the help of new keyword.
Castle Windsor is a best of breed, mature Inversion of Control container available for . NET and Silverlight. The current version is 5.0, released in February 2019. Refer to the links on the right to download it from GitHub or NuGet.
To answer your questions:
- That is using reflection and each time that an object is called from the container, reflection must used so performance will be terrible. (Is this the case? does it use reflection on every call?)
- If I am relying on Interfaces; how do I deal with objects that have extra methods and properties which have been tacked onto the class? (through inheritance)
You also can have class components, but they have limitations, and you must be aware of those (for example you can't intercept calls to non-virtual methods). I have found Windsor to be the most mature, and best suited to my style of development container of all.
Other than that, Performance, I haven't heard of a project that had to discard dependency container because of unacceptable performance. Windsor is really smart about it, and it caches the results of lengthy operations so that you don't have to pay the price twice. You may find charts on the Internet, comparing speed of many IoC containers. Two things to note about those: All containers are really fast. Don't think that the fact that other containers are faster on these charts than Windsor, means that they are better. Windsor does a lot of stuff for you that other containers don't.
I've used IoC containers (Spring.NET and StructureMap) in several production apps under high load (not Facebook/MySpace high, but enough to stress out a few servers).
In my experience, even before I started using IoC, the biggest perf concern is the database and the interaction with the database -- optimizing queries, indexes, using 2nd-level caching, etc.
If you have a database involved with your app, then whatever performance hit Windsor or any other container may cause will be so infintessimally small compared to a DB round trip.
This is like people who compare the performance hit of the new() operator vs. Activator.CreateInstance() at 1-10ms when a single DB roundtrip is usually an order of magnitude more expensive.
I would advise you not to worry about the small stuff and concentrate on the big stuff.
Also, I'd like to advise you to look at StructureMap, as I believe it has a lot more functionality than Windsor and doesn't have a lot of Windsor's shortcomings (i.e. holding on to references and requiring you to release them, etc).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With