Great framework, poor IoC

[JobaDiniz]

MEF is slow, take a look at this benchmark

Conclusion: Ninject is definitely the slowest container. MEF, LinFu and Spring.NET are faster than Ninject, but still pretty slow.

It would be great if the framework allow other IoC rather than MEF. Huge change, I know.

My question is, have anybody tried to change this framework to use another IoC? I'd like some help :)

[mwpowellhtx]

I tend to agree. I use Autofac with pretty good performance. They all do pretty much the same thing. At least to allow swapping out the DI container, along the same lines as ASP.NET MVC does.

[tgjones]

Interesting, I hadn't seen those benchmarks, thanks for linking to them. I remember choosing MEF at the time simply because it came with .NET.

Before we get too into this discussion, I'm curious whether this request is based on benchmarking your Gemini-based application? Because I'd be really surprised if IoC made much of an impact - in the applications I've built with Gemini, th application code far outweighs any IoC costs.

[mwpowellhtx]

I'm sure "it depends", on the kinds of life times involved, initialization "warm up" requirements, and so on.

[JobaDiniz]

Before we get too into this discussion, I'm curious whether this request is based on benchmarking your Gemini-based application.

It's about good practices, I guess. I find it really bad to "import" dependencies onto private fields, static fields or using attributes to configure... Years ago, my IoC choice was Unity, and then I came across that benchmark. Since then, I've been using SimpleInjector, and I came to love it :D

[mwpowellhtx]

@JobaDiniz Totally agree. Nothing worse than a surprise dependency on something like SqlLite, per se. Slightly off topic, but I digress.

[antonfirsov]

@tgjones

in the applications I've built with Gemini, th application code far outweighs any IoC costs.

Ok, but if my of my own (non Gemini-specific) application logic is IoC-intensive, then I

1. Either use MEF everywhere (which makes my app slow)
2. Or use two different IoC frameworks: one (in my case SimpleInjector) for high-performance core application components, and MEF for MVVM & Gemini specific stuff. (Complicated design)

The best solution is to abstract out the Dependency Injection dependency :) Let the user make his choice! See: https://github.com/aspnet/DependencyInjection

[mwpowellhtx]

@antonfirsov I agree. Speaking in terms of ASP.NET, I can replace the default DI in favor or my adoption. In my case I am using Autofac, which is reasonably quick, balanced with features I want.

I find with MEF, it just sounds ugly to begin with; not technical, I know, but it doesn't roll off the tongue. And it is very intrusive.

There's a difference between IoC (i.e. service lookup) and true DI. Not the same animal, when you really stop and look at it closely. Edit: for the most part, I find that if I need to lookup services instead of injecting them, then I am probably not doing something right; have not met a use case that I could not constructor inject, plus I get nice exceptions when something is wrong.

If service lookup is your thing, by all means. For me, as a DI professional, to name a few of my use cases, I aim for Constructor injection, always. Only in a rare circumstance would I consider field and/or property injection, since it is just harder to manage. Sometimes I consider "named" instances if I need some separation at the container level, but only sometimes.

Anyhow, interesting discussion. Could easily be a week or two long course.