Contents tagged with DependencyInjection
-
Ioc Comparison: Autoregistration in Autofac
Autofac is a capable and interesting IoC container. I looked at Autofac for basic IoC here. Implementing my suite of autoregistration tests in Autofac did not require any custom extension classes, autofac handled everything that I asked of it.
Autofac adds registrations in an atomic manner, like StructureMap. But Autofac doesn't use lamdbas - you configure a ContainerBuilder in as many steps as needed, and then create a container from this builder in a single operation.
-
IoC comparison: Autoregistration in StructureMap
The StructureMap IoC container has guidance on using Autoregistration which I followed. Earlier I put StructureMap through its paces for basic IoC.
For Autoregistration, StructureMap uses lambdas, even nested lambdas. The interface is not fluent. The basics are quite simple. StructureMap feels a bit like Ninject under the hood, and there are similarities – both do automatic resolution of unregistered types, and both need custom code to do more complicated Autoregistration scenarios. Both are perfectly usable with a bit customisation.
-
IoC comparison: Autoregistration in Ninject
The Ninject IoC container has an extension that does autoregistration, or "Convention based binding" as they call it. I have looked at basic IoC in Ninject before, and I quite like it. Autoregistration is not a third party add-on, but is part of the ninject source tree here on github. Ninject autoregistration does not work in quite the same vein as Windsor or Unity's fluent interfaces, but it feels like the "Ninject way", i.e. similar to the other parts of ninject such as using classes as modules.
-
IoC comparison: Autoregistration in Microsoft Unity
The Microsoft Unity container does not include autoregistration, so you could do without it, roll your own or use the Unity Auto Registration addon by Artem Govorov. This post looks at Unity with this addon. Like Windsor's autoregistration API, it also uses a fluent interface. Unity's fluent interface starts with the extension method ConfigureAutoRegistration, then follows one or more Include(FilterPredicate, Then.Register.As… ) blocks, and ends with ApplyAutoRegistration();
-
IoC comparison: Autoregistration in Castle Windsor
Castle Windsor emphasises autoregistration, probably more than any other .Net IoC container, and the API to do it is probably the most complete.
Windsor's explicitness about registration - the lack of automatic resolution of unregistered concrete types - turns out to be an asset with autoregistration. In a sense, automatic registration and automatic resolution are two different approaches to the same problem of convention over configuration in that they allow you to create types without mentioning them in the container configuration. But they don't play that well together, and can give confusing results.
-
IoC comparison: OpenRasta Internal Dependency Resolver
OpenRasta is an excellent .Net web framework written by Sebastien Lambla. OpenRasta is open source, is opinionated about REST, but is also highly flexible and configurable. So you can plug any Inversion of Control container into it, but it also contains a basic built-in IoC container that is used if no external container is supplied. Even though this container is not intended for use outside of OpenRasta, I decided to isolate it and put it through my IoC comparison tests.
-
IoC comparison: Spring.NET CodeConfig
Spring.NET has a new add-on called Spring.NET CodeConfig 1.0.1 that I hoped may adress some of what I saw as spring’s shortcomings in my comparisons of .Net IoC containers, specifically it should allow different configs be used in different tests in the same project. The docs for Spring.NET code config are here. it's also on github and nuget and is apparently just "the first step in the process of expanding Spring.NET's support for non-XML-dependent configuration scenarios". It works, and goes about it in a different way which is not as terse and as most other containers.
-
The LightCore IoC container 1.4
I have looked at the LightCore IoC container before in this blog post reviewing it. Now Peter Bucher has released version 1.4.1 of LightCore.
I'm happy to say that this fixes the issue that I had with version 1.0 and things work smoothly.
-
Comparing .Net IoC containers source is now on github
The source for the comparisons that I have done on IoC Containers is now on Github at http://github.com/AnthonySteele/IoCComparison Continue reading...
-
The LightCore IoC container
I have had a look at LightCore, which is written by Peter Bucher, who works in Germany and Switzerland. It is available with source, and has a public SVN repository. The documentation is in German, but it isn't hard to work out what the code samples do. Continue reading...
-
The Funq IoC Container
I was asked to look at Funq, an IoC container that aims to be lightweight and high performance, using lambdas and generics to eliminate the use of runtime reflection. It was made by Daniel Cazzulino (@kzu), and in a series of screen casts he shown the whole process of developing Funq using TDD. This is very impressive and may be a good introduction to TDD, but aside from this, there is little or no documentation. Videos are all very well, but they are no substitute for written code examples. So I may have missed how to do things in Funq. Continue reading...
-
Comparing .Net IoC containers, part seven: MEF
The Managed Extensibility Framework from Microsof is part of the .Net 4.0 framework, but is not an IoC container. Well, not quite, but so close that you might take it for one. It is an Extensibility framework. It really shines when you want to know about all the classes that implement some interface (say IPlugin or IApplicationPart), and get notified when a new one shows up at runtime. So you can get told about all the plugins or components that your application has been given. Continue reading...
-
Comparing .Net IoC containers, part six: Spring.Net
Spring.NET is a port of a popular Java framework called Spring. Spring is very popular in the Java world, and it covers a lot of things, including IoC. Since I am comparing IoC containers in this article, I will address only the IoC aspects of the spring.Net port. Continue reading...
-
Comparing .Net IoC containers, part five: Autofac
I had not used Autofac before this test series, but it used on the Orchard blog engine project and has some interesting advanced features and was quite usable for the basic operations in the tests. The Autofac source code is under the MIT licence is on google code, and is written by Nicholas Blumhardt and other contributors. I have updated this blog post in June 2011 with new code for StructureMap 2, based on the comments by Brendan Forster.
Autofac requires all types to be registered, and creates a new instance each time by default.
With Autofac's syntax we are back in the more familiar terain of RegisterType<T>.As<U>(); and Resolve<T>. Note that the RegisterType<T> happens on a ContainerBuilder, and then a container is built from it which can Resolve. Like StructureMap, this emphasises that registration happens before use. The container is not actually immutable (in version 2 onwards), though it doesn't look like changing a container a lot after setup it is encouraged.
-
Comparing .Net IoC containers, part four: StructureMap
this test was my first use of StructureMap but I know that it was written by Jeremy D. Miller with help from other contributors. The Apache-licenced source is on Github. It's a fairly modern-looking design, using lambdas. In fact, I could criticise it for requiring lambdas and thus more typing where other IoC containers do not require them. But the point of the single method that does all registration is that it is atomic - it prevents the container being used when registration is half-completed. Continue reading...
-
Comparing .Net IoC containers, part three: Ninject
I have used NInject before and found it easy to work with. We used it because at the time it was the only IoC container that worked with Silverlight. The syntax is quite different to the others - you define the configuration in one or more Modules which inherit from NinjectModule, and are then loaded into the kernel. Continue reading...
-
Comparing .Net IoC containers, part two: Castle Windsor
Castle Windsor is perhaps the most well-known .Net IoC container. It is well-established and flexible. Continue reading...
-
Comparing .Net IoC containers, part one: Microsoft Unity
Microsoft Unity is one of the simplest IoC containers to use. You only need a couple of lines of code to get going: Continue reading...
-
Comparing .Net IoC containers, part zero: Groundwork
I started doing some compare and contrast code on well-known .Net Inversion Of Control containers some time in 2009, in order to better convince my colleagues that they should be using a good one. I haven't succeeded yet, but I have reworked the code into a simple and practical survey that may be of use to anyone interested in picking an Inversion of Control Container for .Net code. Continue reading...