一直以来，强类型对象一直是面向对象编程的基础。快进到 5 分钟前，当使用实体框架和 MVC3 时，我被迫将其添加到我的 Web.config 中：
\n\n<connectionStrings>\n <add name="_MY_EXACT_CLASS_NAME_DbContext" connectionString="Data Source=blahblah.../>\n</connectionStrings>\n太棒了，我的整个应用程序依赖于 XML 属性中任意选择的名称。这真的是现代编程的样子吗？类名拼写错误是一种严重的错误，编译器会直接引导我们进行修复，但在这种情况下，我只会收到运行时异常消息。如果前面提到的异常消息先生心情好的话，他会把我引向魔多，然后我就会长途跋涉走向另一座末日山，浪费调试时间来摧毁看不见的“一个打字错误统治他们所有人” 。
\n\n控制器也是如此：
\n\nroutes.MapRoute("BE_CAREFUL","{controller}/{action}/{id}",\n new { controller = "ONE_FALSE_MOVE_AND",\n action = "BUT_I_SWEAR_IT_SAID_BUILD_SUCCEEDED" }\n);\n事情似乎一波一波地来来去去。强类型对象曾经风光无限，现在我们都是匿名“var”的邻家女孩。我承认，对自己的类型含糊其辞会引发很多性感的场景 - 特别是知道你不需要做任何设置工作 - 但这里是实际问题：
\n\n面向对象编程的先驱们对我们通过添加一堆软弱的、无所事事的匿名构造同时创建对命名约定的脆弱依赖来“进步”他们的艺术有何感想？
\n\n据我们所知，MVC4 可能突然要求所有名称前面必须有 4.7 个空格，后跟 lolcat ASCII art。为什么？因为是的，这就是原因。花点时间，惊叹一下您刚刚见证了命名约定的诞生这一事实。显然，这是旗舰框架非常坚实的基础材料。
\n\n因此，如果我希望我的整个代码库在功能上和哲学上都依赖一件事，那么对于编程的数学逻辑来说，没有什么比......微软的\xc2\更关键的任务了。 xae 英语命名约定！
\n\n</sarcasm>\n</griping>\n\n<!-- resume enjoying all of MVC\'s amazing features, after eating any humble pie served up in the comments -->\n