Question

最近在我开发的应用程序中，我一直在检查受插入，更新，删除数据库影响的行数，如果数字是意外的，则记录错误。例如，如果从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);
    }
}

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

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

    return true;
}

在代码隐藏或视图中（我同时执行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
}

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

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

更新

感谢大家花时间回答。我仍然没有100％决定我将继续使用什么设置，但这是我从你的所有回复中拿走的内容。

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

我遗漏的第二个要点会不会有任何问题？

Answer 1

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

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

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

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

修改：我刚刚注意到您的代码中存在潜在有害的错误，与我上面的上一点有关。如果多个记录被更改，该怎么办？它可能不会发生在INSERT上，但很容易发生在UPDATE上。代码的其他部分可能会假设!= 1表示没有更改记录。这可能会使调试成为问题：）

Answer 2

一方面，大多数情况下一切都应该按照您期望的方式运行，并且在那些时候，额外的检查不会向您的应用程序添加任何内容。另一方面，如果出现问题，不了解它就意味着问题可能会在您注意到之前变得非常大。在我看来，一点额外的保护值得花费一点额外的努力，特别是如果你在失败时实现回滚。它有点像你汽车里的安全气囊......如果你永远不会崩溃，它真的没有用处，但如果这样做可以挽救你的生命。

Answer 3

我总是喜欢在我的sproc中raiserror处理异常而不是计算。这样，如果您更新sproc以执行其他操作（例如日志记录/审核），则无需担心要检查行计数。

虽然如果您喜欢代码中的第二次检查或者不想处理异常/ raiserror，我已经看到团队在数据库中的每个sproc成功执行sproc时返回0，并返回另一个数字否则。

Answer 4

这绝对是矫枉过正的。您应该相信您的核心平台（.Net库，Sql Server）正常工作 - 您不应该担心这一点。

现在，您可能需要测试一些相关的实例，例如事务是否正确回滚等等。

Answer 5

如果需要检查，为什么不在数据库内进行检查呢？您可以避免进行往返，并且可以在更“集中”的阶段完成 - 如果您签入数据库，您可以放心，它可以从任何访问该数据库的应用程序中得到一致的应用。如果您将逻辑放在UI中，那么您需要确保命中该特定数据库的任何UI应用程序都应用正确的逻辑并且一致地执行它。

在数据库操作（插入，更新，删除）过度杀伤后检查受影响的行是否计数？

5 个答案: