在哪里进行审核或记录？

Question

我目前正在使用NHibernate处理ASP.NET MVC项目，我需要跟踪某些实体的更改，以便能够对数据进行一些报告和查询。出于这个原因，我希望将数据放在表格中，但我正在尝试决定在哪里“挂钩”审计代码。

在NHibernate层：

• PRO：强大的事件系统来跟踪任何变化
• PRO：在没有通知的情况下，应用程序中没有任何内容可以更改（除非有人使用原始SQL ...）
• CON：因为我有一个通用的存储库......然后我必须过滤掉有用的实体（我不需要跟踪所有内容）。
• CON：我无法轻松访问控制器和操作，因此我只能跟踪基本操作（更新，删除...）。我至少可以获得HttpContext来获取一些信息。

在控制器级别的操作过滤器上：

• PRO：有关请求和Web应用程序状态的完整信息。通过这种方式，我可以将“编辑”与“状态更改”区分开来，并在审计信息中更具描述性。
• CON：有人可以忘记过滤器，可以采取重要措施，恕不另行通知，这是一个很大的问题。

有任何线索吗？

更新：了解如何Create an Audit Log using NHibernate Events。

Answer 1

我认为在存储库级别执行此操作更合适。主要是因为您将来可能决定添加一些访问您的存储库的方法，该方法不通过MVC（例如，数据的WCF接口）。

所以问题就变成了，你如何解决你在NHibernate层上所做的关于它的缺点？

过滤掉有用的实体很简单。我可能会通过实体类型的自定义属性来执行此操作。您可以标记要跟踪的实体或不标记的实体;哪个更容易。

弄清楚控制器的真正意图是什么。我要争辩说你可以“获取HttpContext”;我不认为在存储库中执行此操作是个好主意，因为关注点分离。存储库不应该依赖于Web。一种方法是在存储库上创建自定义方法，以便您以不同方式跟踪操作;如果这些编辑的其他方面表现不同，例如不同的安全性，这尤其具有吸引力。另一种方法是通过比较对象的旧版本和新版本来检查更改，并导出更改的实际性质。第三种方法是不尝试导出更改的性质，而只是将日期和版本之前的版本存储在日志中，以便读取日志的人可以自己解决。

Answer 2

我宁愿把它放在数据（在你的情况下是NHibernate）层。将它放在控制器中并要求其他人（或将来自己）实现控制器与面向对象的设计原则相冲突。

Answer 3

我是用NHibernate做的。需要审计的对象实现IAudtable接口，我使用Interceptor通过拦截OnFlushDirty，OnDelete和OnSave对任何实现IAuditable的对象进行审计。