【问题标题】:Auditing EF no T4审计 EF no T4
【发布时间】:2012-08-19 05:13:37
【问题描述】:

我正在使用 EF 在 MVC3 应用程序中构建某种审计行为,并且我尝试了几种方法,试图避免对代码的高影响,当然,也尽量避免与我可以,因为申请已经完成了 35%。

Audit 对象如下所示:

  • 审核 ID
  • 用户ID
  • 操作 ID
  • 模块 ID
  • 时间戳
  • 有效载荷

思路如下:

我创建了一个部分类来隐藏SaveChanges() 并覆盖SaveChanges(SaveOptions)

然后我创建了两个相同方法的重载来接收我的实体作为参数和/或不是 SaveOptions 枚举参数。

除了显而易见的,新的SaveChanges() 设置了我的Audit 实体的属性,但问题发生在这里:我需要一个UserModule 和一个Operation

我目前的解决方案如下:

  • 我在构造函数类级别声明了一个Audit 对象。
  • 在控制器的构造函数中,我将User 设置为我的Audit 对象。
  • 在每种方法中,我都根据需要设置了Operation
  • 在保存更改中,我处理来自ObjectStateManager 的有效负载(在我的例子中是一个xml)。

I'm very skeptic about this approach, it seems to be a little intrusive to my code. I've read lots of posts here in SO, but none of them helped me to improve this approach nor decide to change it. So please avoid linking things I've probably already read.

【问题讨论】:

  • 最好在数据库级别使用触发器进行审计。

标签: c# asp.net-mvc entity-framework audit


【解决方案1】:

另一种选择是使用自定义属性装饰您希望审核的数据库实体。在 SaveChanges 期间检查属性。对于模块和操作字段,您可以捕获当时的堆栈跟踪 - 从中​​找到调用控制器和操作。这将有助于让您的控制器保持清洁。

我在列级别进行审核,而不是对象。通常我只关心几列,而不是全部。作为参考,这是我的基础DbContext。我订阅了 ObjectContext.SavingChanges 事件,检查标记为已修改的所有内容,然后检查具有自定义 [Audit] 属性的任何属性。这可以很容易地扩展到检查删除。

【讨论】:

    猜你喜欢
    • 2016-05-15
    • 2021-08-06
    • 1970-01-01
    • 1970-01-01
    • 2015-12-14
    • 2011-11-17
    • 2018-11-23
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多