Jul 02, 2014 07:28 AM|Rob89|LINK
I don't think Mark is missing the point, let alone 'in several places'. He's expressing a concern about a design decision and providing code samples to back up what he's saying. I'm currently on the fence - I'd like to see some more info from Microsoft.
It's a very poor library that throws configuration totally over the wall to the library end user and says "You deal with it", particularly when it involves internal implementation objects that end user doesn't see or know anything about.
I don't think anyone is advocating doing that - it's simple enough to provide a default implementation.
It's the *USE* of that factory that's the issue. I now have to choose how I want to use that extension point if I have two competing concerns that need it.
How does having a container solve that? You'll still need a solution that addresses both (or more) concerns. Having a container might make it easier to not notice...
What if I want to add a DI container to an existing application, and I find that someone has already written a custom controller factory?
Well, you could use it or roll your own and configure the application to use it instead.
I'm not sure why you seem to be so aggressively arguing against having a discussion - you haven't really explained what's wrong with factories and façades either, you are just very against not having a container for no discernible reason. I mean saying things
My point here is that you're *STEALING* extensibility from the application author by insisting these extensibility points be used for such common base functionality.
Just makes no sense. Creating controllers (the example you keep using) is very common and very integral to MVC (obviously). The framework exposes an interface and affords the developer the ability to register a custom factory if they want. How on earth is
that "stealing extensibility"?!