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

Raf*_*off 4 c# stored-procedures

问题:使用标准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;
Run Code Online (Sandbox Code Playgroud)

而不是

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?
Run Code Online (Sandbox Code Playgroud)

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

Mar*_*ell 7

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

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


重新传递名称与按位传递,这基本上是execTSQL中关键字的一个特性.有两种用途:

exec MyProc 'abc', 123
Run Code Online (Sandbox Code Playgroud)

要么

exec MyProc @foo='abc', @bar=123
Run Code Online (Sandbox Code Playgroud)

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

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

所以在你的具体例子中:

exec sp_StoredProcedure @Param1, @Param2, @Param3
Run Code Online (Sandbox Code Playgroud)

是按位传递,并且:

exec sp_StoredProcedure @Param1=@Param1, @Param2=@Param2, @Param3=@Param3
Run Code Online (Sandbox Code Playgroud)

是低音的.