search

tgjones / gemini

Gemini is an IDE framework similar in concept to the Visual Studio Shell. It uses AvalonDock and has an MVVM architecture based on Caliburn Micro.
Other
1.09k stars 297 forks source link

Great framework, poor IoC #217

Open JobaDiniz opened 8 years ago

JobaDiniz commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

JobaDiniz commented 8 years ago

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 commented 8 years ago

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

antonfirsov commented 8 years ago

@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 commented 8 years ago

@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.