c# – 我为什么要使用SqlCommand.CommandType = StoredProcedure？

参见英文答案 When executing a stored procedure, what is the benefit of using CommandType.StoredProcedure versus using CommandType.Text? 4个问题：使用标准SQLCommand...

参见英文答案 > When executing a stored procedure, what is the benefit of using CommandType.StoredProcedure versus using CommandType.Text?                                    4个
问题：使用标准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?

我不明白我为什么要做第二个？

解决方法:

第一个是完全冗余的步骤,它强制解析,生成,缓存和执行第二个(但是微不足道的)查询计划.它还提供了很好的机会(例如)忘记添加参数.您还需要考虑第一个中的参数现在按位置(在内部TSQL中)传递,其中 – 在第二个中它们按名称传递;这里通常更喜欢名字.同样,如果你向oCmd.Parameters添加一个新参数,你现在有一个额外的维护步骤来维护内部命令 – 或者冒着引入错误的风险,在第二个例子中你不需要做任何额外的事情.

基本上,第一个例子没有任何积极的东西,也有很多负面因素.

Re-by-name与pass-by-position,这基本上是TSQL中exec关键字的一个特性.有两种用途：

exec MyProc 'abc', 123

要么

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

第一个是旁边的; ‘abc’被传递给MyProc的第一个声明参数,123被传递给MyProc的第二个声明参数.任何其他参数如果有一个参数,则采用其默认值.

第二个是姓名; ‘abc’被传递给名为@foo的MyProc参数,123被传递给名为@bar的MyProc参数.任何其他参数如果有一个参数,则采用其默认值.

所以在你的具体例子中：

exec sp_StoredProcedure @Param1, @Param2, @Param3

是按位传递,并且：

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

是低音的.