如何对对象实施审计跟踪（编程）？
上触发的审计跟踪对象
- OnSaving
- OnDeleting
我需要在我的对象上实现添加/编辑/删除的审计跟踪，我使用 ORM (XPO) 来定义我的对象等。我实现了一个在基本对象的 ，并且我将更改存储在 Audit-AuditTrail (Mast-Det) 表中，以进行字段更改。 等等使用一些调用的方法服务。
如何在 OOP 代码中实现审计跟踪？ 请分享您的见解？ 有什么图案之类的吗？ 最佳实践等？ 另一件事是如何在运行单元测试时禁用审核，因为我不需要审核它们，但因为基础对象具有代码。
对象的更改（编辑/添加/删除）以及需要审核哪些字段更改
I need to implement an audit trail for Add/Edit/Delete on my objects,I'm using an ORM (XPO) for defining my objects etc. I implemented an audit trail object that is triggered on
- OnSaving
- OnDeleting
Of the base object, and I store the changes in Audit-AuditTrail (Mast-Det) table, for field changes. etc. using some method services called.
How do you implement audit trail in you OOP code? Please share your insights? Any patterns etc? Best practices etc? Another thing is that how to disable audit when running unit test,since I don't need to audit them but since base object has the code.
Changes to object (edit/add/del) and what field changes need to be audited
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
如果可以的话，数据库触发器是这里的首选方式。
然而，最近我必须在客户端代码中执行此操作，并且最终编写了一个类，该类在打开对象进行编辑时创建了对象的深层（值）副本，并在保存时比较了两个对象（使用 ToString()仅）并将任何更改写入审核表。
编辑：我在每个我想要考虑可审核的属性上都有一个 [Audit] 属性，并使用反射来查找它们，使得该方法不特定于正在审核的对象。
Database triggers are the preferred way to go here, if you can.
However, recently I had to do this in client-side code and I ended up writing a class that created a deep (value) copy of the object when it was opened for editing, compared the two objects at save time (using ToString() only) and wrote any changes to an audit table.
Edit: I had an [Audit] attribute on each property I wanted to consider auditable and used reflection to find them, making the method non-specific to the objects being audited.
我不知道它是否能与您的 ORM 无缝配合，但我使用了 针对 ERP 应用程序的时间点数据库设计，强烈推荐它。 您可以自动从此架构中获得历史记录和审计以及其他好处。
I don't know if it will fit seamlessly with your ORM, but i used Point-in-Time database design for an ERP application and really recommend it. You automatically get History and Audit from this architecture, as well as other benefits.
如果您创建一组用于与数据库交互的 DAO（数据访问对象），那么我更多地来自软件方面而不是数据库方面。 然后，我会将审计功能插入到需要跟踪的 DAO 中的相应函数中。
数据库触发器解决方案也是可行的，这取决于您喜欢将功能放在哪里，在数据库中还是在代码中。
有很多 ORM（对象关系映射）工具可以为您创建 DAO 层。
I come more from the SW side that the DB side, if you create a set of DAOs (Data access objects) that you use for your interaction with the database. I would then insert the audit functionality into the respective functions in the DAOs that need to be trailed.
The database trigger solution is also feasible, it depends where you like to put your functionality, in the DB or in the code
There are a lot of ORM (Object relational Mapping) tools out there that create the DAO layer for you.
我们使用 AOP（aspectJ 实现）实现了类似的解决方案。 利用这个特定点可以捕获并执行特定操作。
当我们需要时，可以插入和拔出。
如果您确实想在应用程序层执行此操作，我建议这样做。
希望能帮助到你..
We've implemented a similar solution, using AOP (aspectJ implementation). Using this particular points can be captured and specific operations can be performed.
This can be plugged in and plugged off when we like.
If you really want to do it in the app layer, i would suggest this.
Hope it helps..
我已经在 Hibernate（另一个 ORM）中使用会话拦截器完成了此操作。 这样审计代码就与您的代码分开了。
I've done this in Hibernate (another ORM) using an Interceptor for the Session. That way the audit code is seperate from your code.
我知道这并不能回答您的问题，但为了记录，我更喜欢在数据库中处理这种类型的审核逻辑。
I know this doesn't answer your question, but for the record, I prefer to handle this type of auditing logic in the database.
我们有一个表，所有审计跟踪条目都存储在其中。每个表上都有一个数据库触发器（它是通过存储过程放置在那里的，但这与这个答案无关）。 当值更改时，旧值将存储在审计跟踪中。 我们的有点复杂，因为我们还有一个查找表，其中包含我们拥有的每个表的列表，以及另一个表，其中包含每个表的每个字段。 这使我们能够根据第一列中该表的 ID 所在的表来查找审计跟踪中的条目。 然后我们还可以根据第二个表的 ID 确切地知道我们要查找的字段。 这使我们不必存储表名和字段名的字符串。 为了显示它，我们的网格在删除按钮旁边有一个“审核跟踪”按钮。 这将打开一个弹出网格，其中包含该记录的历史记录。 我们使用剑道网格，但这些实现都不是必要的。 该弹出窗口是引导弹出窗口。
We have a table that all audit trail entries are stored in. A database trigger is on every table (it's put there by a stored procedure, but that's not relevant to this answer). When a value is changed, the old value is stored in the audit trail. Ours is a little complex in that we also have a look-up table that contains a list of every table we have, and another table that contains every field for each table. This allows us to look up an entry in audit trail, based on what table it's in by ID of that table in the first column. Then we also know exactly what field we are looking for based on the 2nd table's ID. This keeps us from having to store strings for the table name and the field name. To display it, our grids have an "audit trail" button next to the delete button. This opens a popup-grid with the history of that record. We use kendo grids, but none of this implementation is necessary for that. The popup is a bootstrap popup.