我们目前需要为我们的一些主要业务实体实现审计跟踪生成,通常在这些情况下,我们需要保存更改的每个字段的旧值和新值,以及一些头数据,如时间戳、实体ID和保存的用户。
我明白有不同的方法可以这样做,例如:
基于.NET反射的方法可能需要更长的时间来编写,但如果编写得当,它将足够聪明地包含未来添加的新属性,而不会发生任何代码更改,而且它还可以展开和比较所有子实体(比如添加到主要.NET实体中的其他子实体的集合)。
实际上,我们有一个使用基于.NET的审计跟踪生成的遗留应用程序,我们将整个审计跟踪保存为一个SQL数据库中的XML字段,多年来,审计表现在大约是35 of的数据。
我在想,从以下方面来说,这是一个基于触发的解决方案是多么容易:
..。表演怎么样?
是否有人对这两种方法都有经验,并能提出或指出一些利弊?
发布于 2013-02-26 12:39:57
每个组织对审计的要求都是非常具体的。在我的上一个项目中,我们被要求对发送到实时系统的消息进行审计跟踪。
数量很大..。有些日子超过50 10的文本文件,而在其他情况下,平均10-15 10。
我们使用的第一个解决方案是将其保存在SQL中。
大约2年前
去年
你所选择的是基于你的需要。
发布于 2013-02-26 14:01:33
在过去,对于类似的需求,我已经转向域事件和消息传递。它确实带来了一些复杂性,但也是值得的。我建议至少考虑一下。
本质上,您将通过定义一个在对业务对象进行更改时触发的事件来使更改成为模型的第一类公民。这些事件也可能是捕获业务意图的好方法,而不仅仅是在字段级别上的更改。例如,名为OrderRefunded的业务事件通常是比OrderTotal field changed from 45.00 to 0.00更好的审计点。
使用发布/订阅通过消息传递触发这些域事件允许许多订阅者处理该事件。其中一个订阅服务器可以是审核订阅服务器。这会将所有性能影响(重建索引等)从处理原始请求的域移开,并给审核订阅服务器带来负担。这也意味着您永远不会遇到审计代码中的错误会影响业务事务处理的问题。
另一个好处是需要保存多少数据。这种方法使您的优势是,审核订阅服务器只需保存它打算使用的数据量。关于保存或存档多少数据的规则也本地化在处理审核的服务上。因此,您可以确保不需要存储任何数据。
我过去使用过的工具包括NServiceBus和RabbitMQ。每个人都有自己的好处和责任,这取决于问题。
发布于 2013-02-26 12:52:03
如果将业务实体映射到视图,则可以使用INSTEAD OF触发器生成审计日志。
https://stackoverflow.com/questions/15089207
复制相似问题