ADO.NET：你自己的系统中有很多存储过程吗？

Question

大家好 我们知道SqlCommand对象的CommandType属性有3个选项：TableDirect，Text和StoredProcedure或“SP”。

知道“SP”比其他两个选项更有优势，我的问题是你在自己的系统中制作了很多SP吗？

或者你有什么解决方案而不是创建SP？

谢谢

Answer 1

在所有生产系统中，我使用SP和纯ADO.NET Core来访问数据。系统范围从100-300个表和大约500-1000个存储过程。

大多数数据访问代码都是使用工具生成的。如果您对使用/修改它感兴趣，我已经在我的博客上发布了源代码和示例应用程序。该工具可以在大约20-25秒内生成超过100,000行代码，对着具有大约750个存储过程的数据库。

Data Access Layer - Code Gen

当然，如果您不熟悉数据库，数据建模/设计和存储过程，您可能最好使用Linq to SQL或EF4（实体框架版本4）或类似版本。如果您需要强力性能，那么ADO.NET核心以及存储过程就是您的选择。

Answer 2

除了创建存储过程之外，您还可以使用对象关系映射

如：

linq to sql
Nhibernate
Entity Framework

Data Access :SP's vs ORMs

选择最适合您的方式。

Answer 3

回复：你的第一个问题 沿着存储过程的路径走下去，存储过程的数量在项目的整个生命周期中开始不断增长。在基本的CRUD操作之外，每个存储过程都倾向于紧密绑定到特定问题而不是非常可重用。根据经验，我可以为每个数据表预期8-12个存储过程（不包括参考或代码表，例如州或国家列表）。

非常多的过程会使命名约定非常重要，这样您就可以找到任何东西而无需在视觉上重新扫描整个400-500过程列表。

回复：你的第二个问题 在C＃或VB.NET内部的字符串中编写sql会发生很多丑陋的事情 - 它容易出错，难看等等。

Linq，nHybernate和许多其他人存在，但“概念计数”（你需要学习开始高效的事情的数量）远远高于学习如何用C＃编写一个好的存储过程执行器。

Answer 4

我尝试确保只为数据库功能创建存储过程 - 而不是业务逻辑。

数据库功能当我的数据库架构有点模糊时，我想将其隐藏起来。

业务逻辑，只是我的应用程序添加或更新的方式或者他们做了多少验证等等。