C# 检查行是否会影响数据库操作（插入、更新、删除）过量后的计数？

最近，在我开发的应用程序中，我一直在检查受数据库插入、更新、删除影响的行数，如果该行数出乎意料，则记录错误。例如，在一行的简单插入、更新或删除中，如果从ExcuteNoQuyEL（）调用返回了任意一行以外的行，那么我将考虑该错误并记录它。另外，我现在意识到，当我输入这个时，如果发生这种情况，我甚至不会尝试回滚事务，这不是最佳实践，应该明确解决。无论如何，下面的代码可以说明我的意思：

我将使用一个数据层函数调用数据库：

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);
    }
}

然后是对数据层函数的业务层调用：

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

    return true;
}

在代码隐藏或视图中（我做webforms和mvc项目）：

我越是使用这种类型的代码，我就越觉得它是多余的。尤其是在代码隐藏/视图中。有没有合理的理由认为简单的插入、更新或删除实际上不会修改数据库中正确的行数？只担心捕获一个实际的SqlException然后处理它，而不是每次都对受影响的行进行单调的检查，这是否更合理

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

---

更新

感谢大家花时间回答。我仍然没有100%决定我将继续使用什么设置，但以下是我从您的所有回复中获得的内容

• 信任DB和.Net库来处理查询，并按照设计的方式完成它们的工作
• 使用存储过程中的事务回滚任何错误的查询，并可能使用

  raiseerror

  将这些异常作为SqlException抛出到.Net代码中，后者可以通过try/catch处理这些错误。这种方法将取代有问题的返回代码检查

---

我遗漏的第二个要点会有什么问题吗？

我一直喜欢在存储过程中

引发错误

，处理异常，而不是计数。这样，如果您更新存储过程以执行其他操作，如日志记录/审核，则不必担心检查行计数

---

虽然如果您喜欢代码中的第二次检查，或者不希望处理异常/

raiserror

，但我看到团队在成功执行数据库中的每个存储过程时返回0，否则返回另一个数字。

一方面，大多数情况下，所有事情都应该按照您期望的方式运行，在这些时候，附加检查不会向应用程序添加任何内容。另一方面，如果确实出了问题，不知道就意味着问题可能在你注意到之前变得相当大。在我看来，这一点点额外的保护值得付出一点点额外的努力，特别是如果您实现了故障回滚。这有点像你车里的安全气囊。。。如果您从未崩溃过，那么它就没有真正的作用，但是如果您这样做了，它可以挽救您的生命。

我想问题是，“您为什么要检查这个？”如果只是因为您不信任数据库来执行查询，那么这可能是过火了。但是，可能存在执行此检查的逻辑原因

例如，我曾在一家公司工作，该公司使用此方法检查并发错误。当从数据库中提取记录以在应用程序中编辑时，它将带有

LastModified

时间戳。然后，在执行

更新时，数据访问层中的标准CRUD操作将包括
WHERE LASTMOTITED=@LastModified
子句，并检查记录修改计数。如果没有更新记录，它将假定发生了并发错误

我觉得并发检查有点草率（特别是关于假设错误性质的部分），但它为业务完成了任务

在你的例子中，我更关心的是如何实现这一目标的结构。从数据访问代码返回的
1
或
0
是一个“幻数”。应该避免这种情况。它将实现细节从数据访问代码泄漏到业务逻辑代码中。如果您确实希望继续使用此检查，我建议将该检查移动到数据访问代码中，并在失败时引发异常。通常，应避免返回代码

编辑：我刚刚注意到您的代码中也有一个潜在的有害错误，与我上面的最后一点有关。如果更改了多个记录怎么办？它可能不会发生在
插入
时，但很容易发生在
更新
时。代码的其他部分可能假定
！=1
表示未更改任何记录。这可能会使调试变得非常困难：）
这绝对是过火了。您应该相信您的核心平台（.Net库，Sql Server）工作正常-您不应该为此担心

现在，您可能需要测试一些相关实例，例如事务是否正确回滚等。
如果需要进行该检查，为什么不在数据库本身中进行该检查？您不必进行往返，而是在一个更“集中”的阶段完成—如果您签入数据库，您可以确保它从访问该数据库的任何应用程序中得到一致的应用。然而，如果您将逻辑放在UI中，那么您需要确保访问该特定数据库的任何UI应用程序都应用了正确的逻辑，并且逻辑一致。
对有关返回代码的评论投了赞成票。他们是邪恶的。我与两个开发人员在不同的项目上合作，一个使用1表示成功，另一个使用1表示失败。乱七八糟的东西。@BrendonDugan:事实上，没有nee
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
}