【问题标题】:Grails: Store audit record regardless of success/failure?Grails:无论成功/失败,都存储审计记录?
【发布时间】:2015-08-13 20:25:39
【问题描述】:

在 Grails 中,无论事务如何结束,为某些操作编写审计记录的推荐模式是什么?示例:可能由于多种原因而失败的在线用户注册尝试。

基本假设,业务逻辑仅限于事务性服务方法。

潜在的不确定性:我应该通过在服务中抛出 RuntimeException 来中止事务吗? Grails 指南有点暗示,但Burt Beckwith once said(我敢肯定会轻笑)就像用锤子敲击自己以得到一些照顾。

考虑到包含多个检查的冗长逻辑,当检测到冲突时抛出异常很方便。整个事务应该被回滚,但审计记录应该是一样的。

注意有几个审计 Grails 插件,但它们记录对提交的域对象的更改。

【问题讨论】:

    标签: hibernate grails transactions audit


    【解决方案1】:

    在我们的应用程序中,我们为此使用了Platform Core 插件。基本上,当一些有趣的事情发生时,例如:

    • 用户登录
    • 新用户注册
    • 用户创建了某个业务对象的新实例
    • 用户删除了一些东西
    • 等等……

    我们触发一个事件,如下所示:

    event(
        'myApp.activity', [
        userId: userService.currentUser?.id,
        detail: [name: "some useful information about this activity", timestamp: new Date(), ...],
        activityType: ActivityType.CREATED,
        action: "create",
        ...
    ])
    

    然后我们可以在另一个服务类中定义方法来监听其中一些事件,例如

    @Listener(topic="myApp.activity")
    def audit(parameters) {
        //create an audit record for the thing that just happened
    }
    

    好处是

    • 它将诸如审计逻辑之类的横切内容与应用程序的其他逻辑隔离开来
    • 审核在单独的线程中执行(因此它与触发事件的事物不涉及同一事务)
    • 您可以将多个侦听器方法分配给单个 Activity,以便以后扩展您的应用程序有另一个选择

    【讨论】:

    • 清晰且结构合理。我会加油的!
    猜你喜欢
    • 2022-11-22
    • 1970-01-01
    • 2011-10-21
    • 1970-01-01
    • 2017-11-24
    • 1970-01-01
    • 1970-01-01
    • 2021-09-18
    • 1970-01-01
    相关资源
    最近更新 更多