Jul 02, 2014 05:59 AM|mystere|LINK
I had some of these same thoughts at first but reading the
DI Friendly Framework article Ploeh linked earlier in the thread has gone a long way toward convincing me otherwise. The use of abstract factories combined with a configuration class (which can provide default service implementations) seems like a good
way to maintain a completely flexible design without imposing onerous coding / configuration / wiring duties on the user.
Mark's solution is to "steal" framework extensibility from the application developer, by using the extension methods for something that should be baked directly into the framework. If I have a need to implement a customer controller factory, for instance,
I don't want to be in the situation where my DI framework is already using that extensibility point. And, as I argued in my previous point, this ignores all the other extensibility points which mark suggests the end user should also have to take over.
What's more, the framework now can't take advantage of a container, and must be written to do all the work a container provides. Mark seems to be particularly myopic about the desire to simplify a framework by using a container internally, rather than having
to create a bunch of alternatives to a container just to satisfy a purist approach.
I simply believe that IControllerFactory and it's bretheren are MINE as an application developer to use, and that DI support shouldn't require giving that up.