我看到了大量带有实体框架的MVC DAL示例，但ADO.NET和存储过程没有什么？ 用于创建DAL的“存储库”模式和“单元工作”似乎有一种趋势，类似于：
http://www.codeproject.com/Articles/207820/The-Repository-Pattern-with-EF-code-first-Dependen
如何将此代码库从EF迁移到ADO.net存储过程？
答案 0 :(得分：7)
如何将此代码库从EF迁移到ADO.net存储过程？
由于我们大多数人正在远离存储过程，所以答案很少。
最主要的两个原因是：
将所有业务逻辑放在一个位置可以更容易地读取代码，从而维护应用程序。即编程时你会获得更好的流量。
如果您在SP和.NET代码之间展开业务逻辑，则每次在代码和SP之间切换时都必须进行心理转换（存储状态）。
测试很重要。特别是对于有维护计划的应用。
对于.NET，有几种用于测试代码的工具。所有东西都可以毫不费力地单独测试（没有外部依赖），并且有几篇文章描述了不同的测试技术。
单独测试存储过程很难。
今天的存储过程与参数化查询（即使用参数@userName的查询）相比，几年前（SQL Server 2000及更低版本）没有性能提升。它们应该具有类似的性能，因为现在也为参数化查询保存了执行计划。
但是，如果您的SP中有逻辑处理来自多个查询的结果，那么它们会获得更好的性能，因为您的应用程序和数据库服务器之间不需要往返。但是可以通过不同的应用程序架构轻松补偿。
在走这条路之前要三思而行。这通常是不值得的。在较少的CPU周期中获得的（金钱）通常比创建和维护应用程序所花费的时间少得多。
尽管如此，存储过程可以按照此处的说明使用：http://msdn.microsoft.com/en-us/data/gg699321.aspx