Jul 05, 2014 04:56 AM|ploeh|LINK
My overall concern is how the proposed design will impact my (and everyone else's) development experience. As a frequent user of ASP.NET, it's in my interest to make it as easy to use the framework as possible. The proposed design seems to me to be unnecessarily
complicated, which, I'm worried will negatively impact my productivity as a user of the framework.
My first concern is that the use of a Conforming Container isn't just an optional infrastructure component. Would I mind it if it was an
exclusively optional feature? No, I probably wouldn't, because it would mean that I could just ignore it. However, architectural decisions like that tends to have a big impact on the overall framework, and I would be surprised if the team could pull
it off, making the Conforming Container strictly optional.
What is more likely to happen is that the presence of a Conforming Container will influence future design decisions (after all, there must be a reason why the ASP.NET team thinks this is a good idea). For example, it already seems to me that one of the reasons
such a design is suggested at all, is to enable 'DI support' in attributes: the most straightforward way to do that is to rely on a Static Service Locator (an anti-pattern).
Once you introduce a Static Service Locator into the framework design, it'll spawn more designs utilizing that approach. The next most likely candidate, after attributes, is to 'DI enable' various extension methods (see e.g.
this discussion on why that's a bad idea). At this point, the framework is well under way towards the
Static Spider Web anti-pattern. The code will be difficult to reason about.
The problem regarding the Interface Segregation Principle (ISP) is that
Service Locator breaks it. Once ISP is violated, it's also very likely that the Liskov Substitution Principle is broken, because the more members an interface defines, the more likely it becomes that various implementations change the correctness of the
system (just think about implementations that throw NotSupportedException from various members, like, e.g.