在数据层和应用程序层之间共享消息的最佳方法

时间:2010-07-01 17:30:48

标签: tsql

我一直在寻找任何建议或一个好的方法来处理数据和数据之间的消息。应用程序层,我的意思是当在应用程序中使用存储过程甚至使用直接SQL语句时,应该有一种方法,数据层至少以有组织的方式向上层通知语句/操作结果。

我常用的是每个商店程序中的两个变量:

@code INT,
@message VARCHAR(1024)

我将DML语句放在TRY CATCH块中,并在try块的末尾,将两个变量设置为某个状态意味着一切正常,因为您可能认为我在catch块上执行了相反的操作,如果需要,将两个变量设置为某些失败代码,执行一些错误处理。

TRY CATCH块之后,我使用记录返回结果:

SELECT @code AS code, @message AS message

这两个变量在上层用于验证,如向用户发送消息,也用于提交o回滚事务。

也许我错过了像RAISERROR这样的重要功能,或者没有考虑更好,更优化和安全的方法。

我很感激你的建议和良好做法,而不是要求厨师食谱没有必要,只是想法,但如果你决定加入例子,他们会受到欢迎。

由于

2 个答案:

答案 0 :(得分:1)

我的经验是依靠程序机制的固有运作。我的意思是,如果一个过程失败,则隐式引发的错​​误(如果不使用try / catch ...只是CRUD的东西)或使用显式RAISERROR。这意味着如果代码落入catch块并且我想通知应用程序错误,我将使用RAISERROR重新引发错误。在过去,我已经创建了自定义重新抛出过程,因此我可以捕获并记录错误信息。可以使用重新抛出作为投放自定义消息/代码的机会,该消息/代码可用于引导应用程序沿着不同的决策路径。如果调用应用程序在执行时没有收到错误,则可以安全地假设它成功 - 因此可以开始显式事务提交。

我从未尝试用自己的通信机制编写应用程序和存储过程之间的交互 ​​- 我与之交互的语言中的对象具有检测程序引发的错误的事件或机制。对我来说听起来像你的方法并不一定需要比标准错误处理更多的代码,但我确实发现它令人困惑,因为它似乎是一种重新发明的轮式场景。

我希望我没有误解你在做什么,我也不想成为批评者;但我确实相信,您可以使用标准API提供此反馈机制,并且可能使这个过于复杂。我建议您阅读RAISERROR并查看它是否能满足您的需求(请参阅页面底部的使用RAISERROR链接)。

答案 1 :(得分:1)

普遍接受的处理方法是让你的sproc设置一个返回值 并使用之前建议的加注错误。

我怀疑你缺少的关键是如何在客户端获取这些数据。

如果您在.net环境中,则可以在ado.net代码中检查返回值。可以通过捕获SqlException对象并迭代错误集合来捕获引发错误消息。

或者,您可以创建和事件处理程序并附加到连接InfoMessage事件。这将允许您从sql server生成消息,而不是在批处理或存储过程完成时获取消息。

我不推荐的另一个选项是跟踪你关注的所有内容到XML消息中并从存储过程中返回它,这会给你一些结构,然后是你的自由文本字段方法。