1

从应用程序的角度来看，存储过程允许更好地抽象和分离关注点。在我的公司，有让 DBA 编写程序并完成所有 DB 工作的传统。而且，它是一个最有效的模型。

作为 .NET 开发人员，我使用资源文件来汇总我的所有错误/成功/验证消息。这使我可以将错误消息保持标准化和集中化，因此，一旦实现完成并且我们需要记录“应用程序消息”，该过程就很简单了。

但是，我们的 DBA 有一个坏习惯，即在整个过程中散布错误消息，这使得记录系统变得困难。当前的解决方案是始终返回@Result并@Message使用 Redgate 工具来搜索和查找这些变量。然而，这很乏味，听起来也不是一个很好的解决方案。

我想知道是否有任何推荐的做法来集中数据库端的错误消息，同时仍然不会降低性能？

4

1 回答 1

2

在我们的应用程序中，我们从存储过程中返回一个错误代码。这些错误代码是固定的整数，例如，如果要求更新的用户 ID 在数据库中不存在，我们将返回错误代码 10。我们使用这些错误代码作为资源文件中的键来针对它们定义标准错误消息。

我们还定义了对应于这些错误代码的枚举，只是为了让我们的生活更轻松

于 2012-11-21T03:08:10.173 回答