我是一所老学校，也是MVC的新手。我喜欢更注重行动的MVC。但MS已将它与EF捆绑在一起，现在很难不使用EF。
这就是我的想法：
1 - 假设RDBMS存储的proc / package比LINQ具有更好的性能。例如，SQL Server Transact-SQL现在支持分页，与LINQ相比，TSQL肯定有更好的性能。所以LINQ只对人们在性能方面不了解TSQL或PL / SQL有好处。
2 - 我尝试过使用LINQ w / stored proc。认为它有效但有许多限制，例如，.dbml文件是强类型的，它禁止任何重新格式化数据的尝试，例如向显示字段添加锚点。好吧，有人可能会说你不应该这样做。让我举个例子，企业想要在网格中点击一列。有许多方法可以实现，其中最快的方法是将一个anchorto嵌入从存储过程返回的列中，对UI进行很少的更改。因此QA只需要测试一些。但是使用EF作为基础，任何基于此模型/类的东西都必须再次进行QA。
3 - 模型优先或代码优先不会得到一个很好的规范化大规模数据库实现，这是因为如果开发人员不了解TSQL，他就不会擅长RDBMS设计。
4 - 这是最重要的问题：在企业环境中，我们开发人员无法规定架构和表定义。即使采用DB-first方法，有时我们甚至不知道它来自何处。但这就是EF的优点，对吗？你可能会说。想象一下EF检测所有模式以及从存储过程返回的内容，然后为我构建所有数据层/类。太棒了，但是需要一个实时的中间价格，根本不在数据库中，我们用一些自定义代码添加它。如果需要另一次扫描和检测，它将会消失，因为我们的客户端请求某些东西会导致数据库中的微小变化。我们如何避免丢失定制代码的麻烦？
5 - 有时我们需要在包控制台中运行“update-database”命令，以便EF可以工作。几乎不可能向Operation和DBA解释它们在发布期间是无害的。
然而，随着EF越来越受欢迎，必须有一种新学校的方式来使其发挥作用。有些专家可以教育老派吗？