Rai*_*oad 6 audit entity-framework
我们当前的企业解决方案是由实体框架驱动的ASP.NET MVC应用程序.有几个关于如何挂钩变更事件以进行审计的链接.我对此并不感兴趣.
我对企业级审计架构感兴趣.那些有企业级战斗创伤的人,你的审计解决方案是什么？您是否在框架中序列化数据库中的对象.您是否正在为审计表设置数据库触发器？您是否一起使用单独的数据库,以便您的审计增长不会影响您的应用程序数据库？我对这里经过验证的真实解决方案感兴趣.我知道我们的技术选择(EF)有选择,但我首先对基金会感兴趣.
链接将非常感激.
我见过几种解决方案，但我最喜欢的一种是简单性本身：
创建镜像每个源表的审核表，添加一些额外的列来跟踪更改的日期和类型（如果支持，则插入、更新或删除）以及进行更改的用户。删除所有约束和索引（除非您希望进行大量搜索）。
在表更新逻辑内部（我们使用了过程，但如果有适当的挂钩，没有理由不能使用 OR/M 或其他持久层来完成），同时写入源表和审计表。
这有很多好处，但最大的好处（在我看来）是不必担心或编写所有代码来管理客户端中配对写入操作的事务完整性。