我为什么要使用SqlCommand ?CommandType = StoredProcedure

本文关键字：CommandType StoredProcedure SqlCommand 为什么 | 更新日期: 2023-09-27 17:53:01

问题:使用标准SQLCommand和SQLCommand.ComandType = StoredProcedure有什么区别?

因为我不确定参数是通过名称还是通过顺序传递给命令对象，所以我更喜欢这样:

SqlCommand oCmd = new SqlCommand("exec sp_StoredProcedure @Param1, @Param2, @Param3", oDBConnection);
oCmd.Parameters.Add("Param1", SqlDbType.Bit).Value = var_param1;
oCmd.Parameters.Add("Param2", SqlDbType.NVarChar).Value = var_param2;
oCmd.Parameters.Add("Param3", SqlDbType.NVarChar).Value = var_param3;

而不是

SqlCommand oCmd = new SqlCommand("sp_StoredProcedure", oDBConnection);
oCmd.CommandType = StoredProcedure;
oCmd.Parameters.Add("Param1", SqlDbType.Bit).Value = var_param1;
oCmd.Parameters.Add("Param2", SqlDbType.NVarChar).Value = var_param2;
oCmd.Parameters.Add("Param3", SqlDbType.NVarChar).Value = var_param3;
//Do the parameter names and the parameter order matter here?

我不明白为什么我要做第二件事?

我为什么要使用SqlCommand ?CommandType = StoredProcedure

第一个步骤完全是多余的，它强制解析、生成、缓存和执行第二个(但微不足道的)查询计划。它也提供了很大的机会，使你搞砸(例如)忘记添加参数。您还需要考虑，第一个中的参数现在通过位置传递(在内部TSQL中)，而在第二个中，它们通过名称传递;在这里通常更倾向于使用名字。同样，如果您向oCmd.Parameters添加一个新参数，您现在有一个额外的维护步骤来维护内部命令—或者冒引入bug的风险，而在第二个示例中，您不需要做任何额外的。

基本上，第一个例子没有任何正点，有很多负点。

按名称传递与按位置传递，这基本上是TSQL中exec关键字的一个特性。有两种用法:

exec MyProc 'abc', 123

或

exec MyProc @foo='abc', @bar=123

第一个是按位置;'abc'被传递给MyProc的第一个声明参数，123被传递给MyProc的第二个声明参数。其他参数如果有默认值，则采用默认值。

第二个是by-name;'abc'传递给MyProc的参数@foo, 123传递给MyProc的参数@bar。其他参数如果有默认值，则采用默认值。

所以在你的具体例子中:

exec sp_StoredProcedure @Param1, @Param2, @Param3

是按位置传递的，并且:

exec sp_StoredProcedure @Param1=@Param1, @Param2=@Param2, @Param3=@Param3

bass-by-name。

如microsoft网站所述:

…添加到parameters集合中的参数的名称必须与存储过程中的参数标记的名称匹配。

因此，如果我对不同的存储过程使用CommandType = StoredProcedure相同的代码，那么我需要确保对于可能执行的每个存储过程，它只获取参数集合中与要执行的存储过程命名相同的参数。

相关文章：