关于横切关注点的有趣的 AOP 问题？
考虑一组具有与此类似的方法的 DOA
public void addObject(Long sessionId, Long clientId, Dom obj){...}
现在，每个域 pojo (Dom) 都有一个 sessionId 属性，对于域对象上的每个插入、更新或删除，都有一个 >sessionId 必须通过 setSessionId(Long sessionId) 传递，这样我们就可以知道谁做了什么。但这似乎跨越了我们所有的数据访问内容，我认为 AOP 将是一个很好的工具，可以将 sessionId 插入到 @Before(JoinPoint) 或@Around(ProceedingJoinPoint) 建议。这实际上可行吗？ DAO 大多基于 Hibernate，并带有一些 Spring StoredProcedure。
Consider a set of DOAs with methods similar to this
public void addObject(Long sessionId, Long clientId, Dom obj){...}
Now every domain pojo (Dom) has a sessionId property and for every insert, update or delete on a domain object a sessionId must be passed with setSessionId(Long sessionId)so we can know who does what. But it seems that this cuts across the all the data access stuff we and I think AOP would be a good tool to insert the sessionId in either a @Before(JoinPoint) or @Around(ProceedingJoinPoint) advise. Is this actually feasible? The DAOs are mostly Hibernate based with a few Spring StoredProcedure.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您的 sessionId 参数似乎属于审核方面。在 Hibernate 中，此审计方面通常在 org 的实现中实现.hibernate.Interceptor。
您可以实现与实体和查询的生命周期事件相对应的许多方法。在您的实现中，很容易访问当前的 sessionId（它可以使用 ThreadLocal 变量）。清晰、干净、快速;-)
这可能比自己使用 AOP 更简单，尤其是当您从 Hibernate 获取生命周期事件的回调时。
Your sessionId parameter seem to belong to an audit aspect. In Hibernate, this auditing aspect is typically implemented in an implementation of org.hibernate.Interceptor.
You can implement many methods that correspond to life-cycle event for your entities and queries. In your implementation, it is easy to get access to your current sessionId (it could use a ThreadLocal variable). Clear and clean, fast ;-)
This is probably simpler than doing it yourself with AOP, especially as you get callbacks from Hibernate for life-cycle events.
DAO 层周围的拦截器将难以考虑传递持久性，即级联到关联实体的休眠操作（保存、删除等）。 Hibernate 会话拦截器可以。
无论如何，如果您的拦截器能够以某种方式发现当前会话 ID，则无论哪种方式都可以做到。
An interceptor around your DAO layer will have trouble accounting for transitive persistence, i.e. hibernate operations (save, delete, ...) cascading to associated entities. A Hibernate session interceptor could.
In any case, if your interceptor can somehow discover the current session id, this is possible to do either way.
我不明白为什么你不能这样做，我过去实际上做过类似的事情（稍微复杂一点），帮助我不用交叉重构每个类！
你有没有想过放
公共无效addObject（长sessionId，长clientId，Dom obj）{...}
在父亲/高年级？该方法可以委托每个实现。
I don't see why you couldn't do this, I've actually done something similar (a little more complex) in the past, helped me not cross-refactor every class!
Have you thought of putting
public void addObject(Long sessionId, Long clientId, Dom obj){...}
in an father / upper level class? This method could delegate on each implementation..