8

最近在我一直在开发的应用程序中，我一直在检查受数据库插入、更新、删除影响的行数，并在数量意外时记录错误。例如，如果从 ExecuteNonQuery() 调用返回的行数不是 1 行，则对一行进行简单的插入、更新或删除，我将认为这是一个错误并记录它。此外，我现在在键入此内容时意识到，如果发生这种情况，我什至不会尝试回滚事务，这不是最佳实践，绝对应该解决。无论如何，这里的代码来说明我的意思：

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

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 处理这些错误。这种方法将取代有问题的返回码检查。

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

4

5 回答 5

5

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

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

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

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

编辑：我刚刚注意到您的代码中还有一个潜在有害的错误，与我上面的最后一点有关。如果更改了多个记录怎么办？它可能不会发生在 上INSERT，但很容易发生在 上UPDATE。代码的其他部分可能假设这!= 1意味着没有更改记录。这可能会使调试变得非常有问题:)

于 2012-04-30T14:28:54.517 回答
2

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

于 2012-04-30T14:28:45.670 回答
1

我一直更喜欢raiserror在我的存储过程中处理异常而不是计数。这样，如果您更新 sproc 以执行其他操作，例如日志记录/审计，您不必担心检查行数。

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

于 2012-04-30T14:27:16.780 回答
0

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

于 2012-04-30T14:34:45.190 回答
0

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

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

于 2012-04-30T14:29:20.190 回答