NHibernate：使用Interceptor或Triggers审计日志记录？

Question

触发器似乎是审核日志记录的简单解决方案。我为什么要使用拦截器？

1. 数据库可移植性是一个触发因素......

其他人是什么？

Answer 1

使用除触发器之外的任何内容的结果是，并非所有数据更改都可能通过GUI发生，因此可能无法记录。您必须考虑从查询窗口中的许多来源（包括数据导入和基于集合的查询）更改数据库（例如，当有人要求将所有价格更新10％时）。如果您使用其他方法，则最好确保它捕获数据可以更改的任何方式。如果您完全使用动态sql，那么所有表都向用户开放，以便直接在数据库中进行更改，包括旨在从公司窃取的欺诈性更改。提交欺诈的用户是审计触发器旨在捕获的关键事项之一。如果您认为您的审计解决方案是正确的，因为它从用户界面捕获了一切，并且它需要捕获所有内容，那么您就非常非常错误。我不知道拦截器是如何工作的，但是在您认为解决方案可行之前，您最好使用SSIS（或DTS）导入和查询窗口中的查询进行测试。此外，如果它只是从GUI工作，请记住可能有多个GUI连接到数据库。

Answer 2

我认为使用拦截器的原因有两个：

1. 这样您就不会将自己绑定到特定的数据库。移植到不同的DBMS非常容易。

2. 这样您的域模型就不会渗透到代码的其他区域。即数据库需要知道记录是否已经改变。

但这一切都取决于具体情况。如果对特定记录的所有更改都是必要的，那么我认为HLGEM是正确的。触发器最适合处理这种类型的senario。

Answer 3

我同意HLGEM。 具有同时具有DBMS触发器和可移植性优点的一个很好的替代方法是使用一些审计工具： 给出审计计划：为适当的DBMS生成触发器

Pablo Javier

Answer 4

另一个小问题是触发器执行任何DML。 nHibernate使用受影响的行数来确定其许多操作的成功。如果您正在进行任何插入/更新/等。在你的触发器中，你需要在触发器内部转动NOCOUNT以防止那些错误的行计数冒泡。

这并不是说，无论如何，这会阻止你使触发器工作，但我已经花了足够的时间来重构这个问题，我认为值得一提。拦截器或EventListeners是一种简单，可移植的方式来满足审计要求。

另外，没有更多icky T-SQL代码...

Answer 5

触发器不易测试，实际上很难正确编写。如果您的审计数据要由业务用户使用，则通常很难将数据库行级操作转换回域模型。

我认为数据库实际上只是应用程序的持久性区域。一个应用程序。换句话说，我不认为其他系统应该直接使用我的数据库，所以我认为审计是在数据库之外完成的（即没有触发器）。