When requiring to use dependency injection, I always use IoC containers such as Ninject, Unity, or the built-in one in ASP.Net Core MVC. However, I've just come across the idea of "why not creating an object factory" and then instead of intercepting calls to parameterized constructors (via IoC containers), retrieve those objects from the factory in a parameterless constructor. For instance:

Dictionary<Type, Func<Object>> TransientFactory;
Dictionary<Type, Object> SingletonFactory; 

In my opinion, this technique would speed up the whole thing, but I'm not sure to what extent that would be true and that is the point of the question. Considering the fact that the life-cycle of the object can be easily controlled in consuming context, what possible advantages can an IoC container provide in this case?

  • By speed up, do you mean "make it faster to develop" or "make it run faster"? – joshp Dec 16 '17 at 20:26
  • @joshp: It makes it slower to develope (more coding needed) but faster to run. – Arrrr Dec 16 '17 at 20:26
  • 1
    please don't cross-post: stackoverflow.com/questions/47849411/… "Cross-posting is frowned upon as it leads to fragmented answers splattered all over the network..." – gnat Dec 16 '17 at 20:26
  • 1
    It's not practical to ask whether IOC makes code run faster or slower without talking about specific cases with specific libraries. Often the difference is insignificant. As for making it slower or faster to develop that depends greatly on how to the IOC container is used and how well it fits the team's skills. Some teams lose a lot of time on confusion and troubleshooting hell with IOC. Others see it as a boost to productivity. – joshp Dec 16 '17 at 20:33
  • 2
    I think your question is almost impossible to understand without a real example. Can you show some snippet which contrasts the resulting differences in code between an IoC approach and your approach? – Doc Brown Dec 17 '17 at 7:09