EF或SQL是审计数据更改的更好选择吗？

Question

该要求看起来很简单：当数据发生变化时，审核更改。

下面是一些重要的部分公式：

1. 数据在我的应用跨越多个表（一些交叉参考表）。
2. 我的DTO很深，导航属性有条件地填充。
3. 加载时，我用原始值复制原始DTO。
4. 当请求保存时，原始DTO包含更改。
5. 理想情况下，外键会像有用的文本一样读取而不是Id号码。

与TFS的酷历史功能不同，由于许多相关的表和有条件的子实体，我的看起来更复杂。

我看到三种可能性（到目前为止）：

1. 我可以使用C＃来反映的对象和创建前/后记录。
2. 我可以使用SQL 2008R2中的触发器捕获更改并合并前/后记录。
3. 我可以在对象之前/之后存储原始数据，并让SQL 2008R2解析它们。

请注意：现在，我认为SQL 2008R2的CDC太过于沉重的选择了。我真的在寻找我可以建立的东西，但我承认我的想法现在对任何事情都是开放的。

我的问题

之前，我开始构建这样的： 如何其他人办理审计一个复杂的EF DTO？

是否有可用的低（ish）技术解决方案？

预先感谢您。

相关，但不是-完全相关的StackOverflow上已经问题：Implementing Audit Log/Change History with MVC & Entity Framework和Create Data Audit in SQL Server和https://stackoverflow.com/questions/5773419/how-to-audit-many-to-many-relationship-in-entity-framework和Maintaining audit log for entities split across multiple tables和Linq to SQL Audit Trail/Audit Log: should I use triggers or doddleaudit?没有提供答案。

Answer 1

，引发剂溶液，优点：

1. 不能绕过审计

，引发剂溶液，缺点：

1. 不能审计非SQL数据
2. 不能审计在插入复杂的对象

实体框架，优点：

1. 可以审核一切
2. 可以在任何状态下

实体框架，缺点审核复杂的对象：

1. 可以被旁路（如指示 - to-SQL）
2. 需要原始值的副本

我的选择是实体框架。使用STE可以更轻松。

无论哪种方式，你必须推出自己的。

Answer 2

我最近在Entity Framework上实现了一个审计日志管理器。当我实例化我的审计经理时，我反映了所有的实体类，并存储了属性信息。然后在对象上下文SavingChanges事件中，我审核所有更改。它效果很好。在外键的情况下，我只是在更改之前和之后存储他们的Id。

这个解决方案的好处是它不需要任何额外的编码。一旦创建了排序日志管理器，您就不必担心添加新触发器或添加新列时修改触发器。反映类时，您的实体类的任何更改都会自动被选中。

Answer 3

IF审计是一个真正的需求我会选择引发剂溶液......因为其他方法还有许多“短板”：

• “盲”任何修改通过其他手段，而不是你的应用程序
发生
• 如果代码做一些更改，忘记添加审计代码审计跟踪得到“盲点”

基于触发器的解决方案，可以保证只允许特定用户甚至可以看到审计数据.. 。

我通常与Oracle一起工作，但根据我在这种情况下的经验：只允许应用程序通过视图选择权限，任何插入/删除/更新都应通过存储过程完成，审计跟踪应通过触发器完成...

Answer 4

好吧，让我们来看看。 SQL Server auditing已经存在，随工具一起提供，可能已经由您的DBA知道，不会降低您的应用速度，并且可以跟踪events that the application itself will never even see。

另一方面，在EF中滚动自己将允许您审计非SQL Server数据源。它也不需要EE。