在数据库操作(插入,更新,删除)过度杀伤后检查受影响的行是否计数?

rya*_*lit 7 c# sql-server asp.net

最近在我开发的应用程序中,我一直在检查受插入,更新,删除数据库影响的行数,如果数字是意外的,则记录错误.例如,如果从ExecuteNonQuery()调用返回任何数量的行而不是一行的简单插入,更新或删除一行,我将认为是错误并记录它.此外,我现在意识到,当我键入此内容时,如果发生这种情况,我甚至不会尝试回滚事务,这不是最佳做法,应该明确解决.无论如何,这里的代码来说明我的意思:

我将有一个数据层函数来调用db:

public static int DLInsert(Person person)
{
    Database db = DatabaseFactory.CreateDatabase("dbConnString");

    using (DbCommand dbCommand = db.GetStoredProcCommand("dbo.Insert_Person"))
    {
        db.AddInParameter(dbCommand, "@FirstName", DbType.Byte, person.FirstName);
        db.AddInParameter(dbCommand, "@LastName", DbType.String, person.LastName);
        db.AddInParameter(dbCommand, "@Address", DbType.Boolean, person.Address);

        return db.ExecuteNonQuery(dbCommand);
    }
}
Run Code Online (Sandbox Code Playgroud)

然后业务层调用数据层函数:

public static bool BLInsert(Person person)
{
    if (DLInsert(campusRating) != 1)
    {
        // log exception
        return false;
    }

    return true;
}
Run Code Online (Sandbox Code Playgroud)

在代码隐藏或视图中(我同时执行webforms和mvc项目):

if (BLInsert(person))
{
    // carry on as normal with whatever other code after successful insert
}
else
{
    // throw an exception that directs the user to one of my custom error pages
}
Run Code Online (Sandbox Code Playgroud)

我使用这种类型的代码越多,我就越觉得它有点矫枉过正.特别是在代码隐藏/视图中.有没有合理的理由认为简单的插入,更新或删除实际上不会修改数据库中正确的行数?是否更有理由担心捕获实际的SqlException然后处理它,而不是每次都对受影响的行进行单调检查?

谢谢.希望你们都能帮助我.


UPDATE

谢谢大家花时间回答.我仍然没有100%决定我将继续使用什么设置,但这是我从你的所有回复中拿走的东西.

  • 信任DB和.Net库来处理查询并按照设计的目的完成它们的工作.
  • 在我的存储过程中使用事务来回滚有关任何错误的查询,并可能用于raiseerror将这些异常作为SqlException返回到.Net代码,它可以使用try/catch处理这些错误.这种方法将取代有问题的返回码检查.

我错过了第二个要点会不会有任何问题?

Dav*_*vid 5

我猜这个问题变成了,"你为什么要检查这个?" 如果只是因为你不相信数据库来执行查询,那么它可能是过度的.但是,执行此检查可能存在逻辑上的原因.

例如,我曾在一家公司工作过,使用此方法检查并发错误.当从数据库中提取要在应用程序中编辑的记录时,它将带有LastModified时间戳.然后,数据访问层中的标准CRUD操作将WHERE LastMotified=@LastModified在执行UPDATE并检查记录修改计数时包含一个子句.如果没有更新记录,则会假定发生了并发错误.

我觉得对于并发检查(特别是关于假设错误的性质的部分)来说有点草率,但是它为业务完成了工作.

在你的例子中,我更关心的是如何实现这一目标的结构.从数据访问代码返回的1或是0"神奇数字".应该避免这种情况.它将实现细节从数据访问代码泄漏到业务逻辑代码中.如果您确实想继续使用此检查,我建议将检查移入数据访问代码并在失败时抛出异常.通常,应避免返回代码.

编辑:我刚刚注意到代码中存在潜在有害的错误,与我上面的上一点有关.如果更改了多条记录怎么办?它可能不会发生在一个INSERT,但很容易发生在一个UPDATE.代码的其他部分可能会假设!= 1没有记录被更改.这可能会使调试很成问题:)