12

Has anyone started a project to do IOC at compile time (possibly using Roslyn or Linq MethodInfo emit)?

My experience with IOC containers has thus far been great, baring a few small issues

  1. Many IOC containers are slow to start up, as much of the resolution logic occurs here
  2. It is often hard to ensure that resolution is possible, as compilation no longer ensures that the constructor can be called
  3. Often IOC containers add a small overhead to the runtime (some aren't even small, often the ones that start up quickly run slowly)

It seems to me that the ideal solution would be to add a compile step to the build chain that adds a Factory class instead of IOC.

Has anyone done this before? If not, why not?

Improve this question

3 Answers 3

Reset to default
4

Doing this should not be such a problem. Just run same IoC logic and instead of instantiating the classes, you emit code that does the instantiating.

But by doing this, you are removing one huge advantage of IoC : Ability to change how the coponents are composed without having to recompile the whole application. Just by replacing the config, you can have application use different services or data sources. And while I have yet to see application that would make full use of this capability, it is still major part of IoC's success.

Improve this answer
4
  • Yes I know it is possible. But I have yet to see an IoC container that does it. Also I have noted that the current trend seems to be towards registration in code (fluent APIs). Given that, I am considering writing said IoC container.
    – ArTs
    Apr 9, 2014 at 10:37
  • I seem to remember Hiro ( github.com/philiplaureano/Hiro ) might do its stuff at compile time.
    – lzcd
    Apr 10, 2014 at 0:46
  • 3
    "But by doing this, you are removing one huge advantage of IoC : Ability to change how the coponents are composed without having to recompile the whole application." It seems to me that applying this to the entire application is overkill; you're turning every part of the application into a plug-in. Additionally, both techniques should be able coexist - there's no reason you can't wire some of the components at compile time and some at runtime.
    – Doval
    Apr 15, 2014 at 11:42
  • I don't see how that's a huge advantage. In what context are you completely replacing components at runtime? A few config use cases maybe?
    – andyczerwonka
    Dec 7, 2016 at 14:56
4

Dagger for Java/Android does that. It sacrifices some runtime magic (like Guice's) to offer an almost completely compile-time codegen experience, including converting most runtime errors to compilation errors.

Would be cool in .NET too.

Improve this answer
2

I'm working on a project to do exactly this, using Roslyn's preview SourceGenerators. It does all the wiring up at compile time, and gives you compiler errors/warnings if you make a mistake.

Try it out at https://github.com/YairHalberstadt/stronginject

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.