I must say I was very impressed with the performance benchmarks I've seen out there regarding Simple Injector as well as the documentation you are providing.
I'm looking into DI frameworks for my company's new product and came across SI.
There is already new developments using Unity for Web applications. The natural way would be to go with Unity. The new product is to be a cloud based multi-threaded application with multiple activations per second so completely different picture.
I have two questions that could help me a lot to decide and influence decisions.
1 - What motivated you on developing such a framework considering the existing ones out there? If it was performance I would like to know about that business case
2 - What are the concrete feature limitations on this framework? From what I'm seeing it can do almost everything as Unity.
Tnks in advance,
May 8, 2013 at 10:46 AM
Edited May 8, 2013 at 6:15 PM
Simplicity is one of the main goals of Simple Injector and Simple Injector tries to make it easier for developers to start with Dependency Injection. The feature set of Simple Injector is deliberately stripped and with that it tries to push developers in a
certain direction that we feel is best; results in the most maintainable software. This doesn't mean that it is limited in its possibilities, but forces you to do a bit more work to get certain behavior. Take for instance making
registrations with by name/key
implicit property injection
. Both features are possible to implement in Simple Injector, but not supported out-of-the-box (OOTB), because they are abused most of the time and can lead to DI configurations that are hard to verify. We do however provide documentation
that explains most scenarios that are not supported OOTB.
Many developers fear the performance of their DI container. In reality most of the time your container´s performance isn´t an issue, but on the other hand, it´s hard to intuitively sense where the performance bottlenecks are and how to solve them. That is something
Simple Injector tries to solve. Everything you do OOTB is fast. About as fast as when wiring things by hand (except the constant overhead a call to GetInstance() has, and the one-time performance hit of the initialization phase). This allows developers to
stop worrying about the container's performance.
Simple Injector however is specially designed with a specific type of architecture in mind. Architectures that are based on the SOLID principles, work with generic abstractions, and use decorators to apply crosscutting concerns (take a look
for examples of this type of design). Especially the area of using decorators is where other containers lack and where Simple Injector tries to fill a gap. Most containers use a method called interception to apply crosscutting concerns to types, and
make it really hard to apply decorators in a way that is maintainable. In our opinion, the use of decorators is much better than using interception, because decorators don´t force you to take a dependency on some interception library, and results in code that
is simpler and faster. Simple Injector for instance, makes it very easy to apply (generic) decorators conditionally, based on either a predicate or a generic type constraint.
Unity makes it possible to apply decorators, but when it comes to applying decorators conditionally, this gets really hard in Unity, and will lead to a DI configuration that becomes unmaintainable. Whether or not this is a problem, depends on the size and design
of your application, of course.
Of course I´m biased about Simple Injector, and would argue that you can do anything with Simple Injector, but perhaps not OOTB. There are things that are not supported by Simple Injector OOTB but are in Unity are for instance keyed registration, interception,
and handling types with multiple constructors. Simple Injector on the other hand is very fast and has brilliant support for generic decorators.
The choice is up to you.