3

我看到大量带有实体框架的 MVC DAL 示例，但对于 ADO.NET 和存储过程却没有？用于创建 DAL 的“存储库”模式和“工作单元”似乎有一种趋势，类似于：

http://www.codeproject.com/Articles/207820/The-Repository-Pattern-with-EF-code-first-Dependen

如何将此代码库从 EF 迁移到 ADO.net 存储过程？

4

1 回答 1

7

如何将此代码库从 EF 迁移到 ADO.net 存储过程？

由于我们大多数人正在远离存储过程，因此您得到的答案很少。

最大的两个原因是：

控制业务逻辑

将所有业务逻辑放在一个地方可以更轻松地阅读代码，从而更轻松地维护应用程序。即，您在编程时会获得更好的流程。

如果您在 SP 和 .NET 代码之间展开业务逻辑，则每次必须在精神上转换（存储状态）才能在代码和 SP 之间切换。

更容易测试

测试很重要。特别是对于有维护计划的应用程序。

对于 .NET，有多种工具可用于测试您的代码。可以毫不费力地单独测试所有内容（没有外部依赖项），并且有几篇文章描述了不同的测试技术。

孤立地测试存储过程很困难。

误区：存储过程比 SQL 查询快。

@userName今天，存储过程并没有像几年前（SQL Server 2000 及更低版本）那样在参数化查询（即使用参数 as 的查询）上获得性能提升。它们实际上应该具有类似的性能，因为现在也为参数化查询保存了执行计划。

但是，如果您的 SP:s 中有处理来自多个查询的结果的逻辑，它们确实会获得更好的性能，因为您的应用程序和数据库服务器之间不需要往返。但是可以很容易地通过不同的应用程序架构来弥补。

结论

走这条路之前要三思而后行。通常不值得。您在更少的 CPU 周期中获得的（金钱）通常远少于创建和维护应用程序所花费的时间。

也就是说，可以按照此处的说明使用存储过程：http: //msdn.microsoft.com/en-us/data/gg699321.aspx

于 2013-05-28T14:09:06.420 回答