NHibernate 和 SqlServer 中的数据审计
我在一个项目中使用NHibernate,我需要进行数据审计。 我在 codeproject 上找到了这篇文章,其中讨论了 IInterceptor 接口。
您审核数据的首选方式是什么? 您使用数据库触发器吗? 您使用与文章中讨论的类似的东西吗?
I'm using NHibernate on a project and I need to do data auditing. I found this article on codeproject which discusses the IInterceptor interface.
What is your preferred way of auditing data? Do you use database triggers? Do you use something similar to what's dicussed in the article?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
作为一种完全不同的方法,您可以在存储库中使用装饰器模式。
假设我有
然后,我们会有 NHibernateRepository:
然后我们可以有一个审核存储库:
然后,使用 IoC 框架(StructureMap、Castle Windsor、NInject),您可以构建所有内容,而无需其余代码知道您有审计正在进行中。
当然,如何审核级联集合的元素完全是另一个问题......
As an entirely different approach, you could use the decorator pattern with your repositories.
Say I have
Then, we'd have our NHibernateRepository:
Then we could have an Auditing Repository:
Then, using an IoC Framework (StructureMap, Castle Windsor, NInject) you could build it all up without the rest of your code every knowing you had auditing going on.
Of course, how you audit the elements of cascaded collections is another issue entirely...
我知道这是一个老问题。 但我想根据 NH 2.0 中的新事件系统来回答这个问题。 事件监听器比拦截器更适合类似审计的功能。 Ayende 上个月在他的博客上写了一个很好的例子。 以下是他的博客文章的 URL -
ayende。 com/Blog/archive/2009/04/29/nhibernate-ipreupdateeventlistener-amp-ipreinserteventlistener.aspx
I understand this is an old question. But I would like to answer this in the light of the new Event System in NH 2.0. Event Listeners are better for auditing-like-functions than Interceptors. Ayende wrote a great example on his blog last month. Here's the URL to his blog post -
ayende.com/Blog/archive/2009/04/29/nhibernate-ipreupdateeventlistener-amp-ipreinserteventlistener.aspx
我更喜欢你提到的 CodeProject 方法。
数据库触发器的一个问题是它让您别无选择,只能使用集成安全性和 ActiveDirectory 来访问 SQL Server。 原因是您的连接应该继承触发连接的用户的身份; 如果您的应用程序使用名为“sa”的帐户或其他用户帐户,则“user”字段将仅反映“sa”。
这可以通过为应用程序的每个用户创建一个命名的 SQL Server 帐户来覆盖,但这对于非 Intranet、面向公众的 Web 应用程序来说是不切实际的。
I prefer the CodeProject approach you mentioned.
One problem with database triggers is that it leaves you no choice but to use Integrated Security coupled with ActiveDirectory as access to your SQL Server. The reason for that is that your connection should inherit the identity of the user who triggered the connection; if your application uses a named "sa" account or other user accounts, the "user" field will only reflect "sa".
This can be overriden by creating a named SQL Server account for each and every user of the application, but this will be impractical for non-intranet, public facing web applications, for example.
我确实喜欢提到的拦截器方法,并在我当前正在进行的项目中使用它。
然而,一个值得强调的明显缺点是,这种方法只会审核通过您的应用程序所做的数据更改。 任何直接的数据修改,例如您可能需要不时执行的临时 SQL 脚本(这种情况总是会发生!),都不会被审核,除非您记得同时执行审核表插入。
I do like the Interceptor approach mentioned, and use this on the project I'm currently working on.
However, one obvious disadvantage that deserves highlighting is that this approach will only audit data changes made via your application. Any direct data modifications such as ad-hoc SQL scripts that you may need to execute from time to time (it always happens!) won't be audited, unless you remember to perform the audit table insertions at the same time.
对于 NHibernate 2.0,您还应该查看事件侦听器。 这些是 IInterceptor 接口的演变,我们成功地将它们用于审计。
For NHibernate 2.0, you should also look at Event Listeners. These are the evolution of the IInterceptor interface and we use them successfully for auditing.
[编辑]
NH2.0 发布后,请查看下面建议的事件监听器。 我的答案已经过时了。
IInterceptor 是以非侵入方式修改 nhibernate 中任何数据的推荐方法。 它对于数据解密/加密也很有用,而您的应用程序代码不需要知道。
数据库上的触发器将日志记录(应用程序关注点)的责任转移到 DBMS 层,从而有效地将日志记录解决方案与数据库平台联系起来。 通过将审核机制封装在持久层中,您可以保留平台独立性和代码可移植性。
我在生产代码中使用拦截器来在一些大型系统中提供审核。
[EDIT]
Post NH2.0 release, please look at the Event Listeners as suggested below. My answer is outdated.
The IInterceptor is the recommended way to modify any data in nhibernate in a non-invasive fashion. It's also useful for decryption / encryption of data without your application code needing to know.
Triggers on the database are moving the responsibility of logging (an application concern) in to the DBMS layer which effectively ties your logging solution to your database platform. By encapsulating the auditing mechanics in the persistance layer you retain platform independance and code transportability.
I use Interceptors in production code to provide auditing in a few large systems.