Nov 29, 2014 03:25 AM|ploeh|LINK
While I left a comment over on that article, I'm repeating it here for good measure:
Thank you for writing this detailed description of the planned 'DI Support' for ASP.NET vNext. It was interesting to see if I had originally misunderstood the intention and planned implementation. Sadly, this post only confirms what I already knew.
While it's a long post, I'm not going to address each point here, because it builds on two fundamentally flawed premises. Once you understand that these premises don't hold, the rest of the arguments crumble as well.
The first flaw in the reasoning is a basic misunderstanding of the Liskov Substitution Principle (LSP). The present article states that "since we are developing against interfaces, DI works on interface and the service locator works on interfaces, we can
replace the used type by a more specific type."
This sentence represents a failure to understand the LSP. You should reread
Robert C. Martins paper about the LSP, which contains an easy-to-understand example of how programming to an interface isn't enough
You could also refer to Krzysztof Cwalina, one of the original API designers of .NET, who
explains the same type of problem without ever naming the LSP.
Sadly, it seems that the ASP.NET vNext designers have already forgotten their roots, although they are only about ten years old.
Those who cannot remember the past are condemned to repeat it.
The second flaw in the present article is that it betrays the most common, but incorrect, limited view of DI that DI is intrinsically tied to use of a DI Containter - at least in some sort of abstract form.
DI is simply the application of the Dependency Inversion Principle. If
Pure DI isn't an option in a framework, it's not DI, but, instead, Service Locator, which is the
opposite of DI.