Dynamic Proxy - Implementing an Abstract Factory‏

Aug 11, 2014 at 3:44 PM
Edited Aug 11, 2014 at 3:45 PM
What are your thoughts on the dynamic proxy technique for implementing an Abstract Factory that Mark Seemann talks about here?

I'm not sure it would actually reduce vendor lock-in but it does reduce the number of classes that have a direct reference to the container.
Aug 11, 2014 at 5:54 PM
There are two main reasons why developers write a lot of factories. They either think they need more control over the lifetime of their objects or they mix runtime data with behavior.

They often forget that with dependency injection, services are created and managed by a third-party. The component itself doesn't have to ask about them, which is what you do when you define a factory. A factory is another layer of indirection, while there's often no need for that when applying dependency injection correctly.

Developers often want to use some runtime data to build up their services. This prevents them from being able to those services together with the rest of the graph and causes them to postpone their creation. To create such service you need a factory where you pass the runtime data to the factory method. The error however is in mixing runtime data with behavior. Runtime data should be passed on through method calls, not using a constructor. Constructors are for dependencies and configuration data; not runtime data!

The factory design pattern is useful, even in the context of dependency injection. But the amount of factories you need will drastically decrease when you apply dependency injection correctly.

Simple Injector's phylosophy is all about educating developers and pushing them into the right direction. Implementing a factory facility is not going to help getting that message across and doesn't help them understand what the root cause is of why they need this facility.

If the user only needs only a few factory implementations, it will be much more convenient to hand-write them and place them in the composition root, such factory facility is all about implicitness. Things often fail silently when the constructor arguments of the implementation is reordered, or a different implementation is used. These problems can be easily prevented when those factories are hand-written, because our compilers and IDEs help us out with this.

Simple Injector on the other hand is all about explictness and failing fast. That's another reason why such feature doesn't fit our design strategy.
Marked as answer by dot_NET_Junkie on 8/11/2014 at 12:10 PM