用于缓存的 AOP x IoC
您是否更喜欢在方法（任何 DAO 或服务方法）之上使用 AOP 缓存层的干净方法，还是更喜欢在需要的地方注入缓存实例的完全控制方法？
我知道 AOP 为您提供了松散耦合和关注点分离，但没有那么多灵活性，除非您自己编写方法拦截器。
我倾向于喜欢 IoC 方法，因为如果需要，可以轻松模拟缓存实例，并且通过缓存实例，您可以拥有完全的控制权和灵活性。
这就像伐木一样。谁真正使用 AOP 进行应用程序范围的日志记录？
Do you prefer the clean approach of an AOP cache layer on top of your methods (any DAO or service method) OR do you prefer the total control approach of injecting a cache instance wherever you need?
I understand AOP gives you loose coupling and separation of concerns, but not so much flexibility, unless you are coding the method interceptors yourself.
I tend to like the IoC approach, because a cache instance can be easily mocked if you need to and with an instance of the cache you have total control and flexibility.
It is like logging. Who actually uses AOP for application wide logging?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是关于我们是否应该使用“真正的”AOP 的问题（“真正的”我的意思是量化和遗忘，以便您可以全局启用方面并且 100% 透明）对于系统）。我的观点是尽可能避免使用 100% 透明的解决方案。如果您处于开发阶段，最好以不强迫您在中间代码级别执行 AOP 编织等技巧的方式设计您的系统。
另一方面，为您需要的每个组件/接口编写缓存关注点将是相当令人不安的，无论您将如何做。我想到的最明显的方法是为每个缓存的类提供一个缓存装饰器类 - 一件事情要做很多次。
因此，我将尝试遵循的路径是使用一些基于动态代理的 IoC 扩展来完成 AOP。当从 IoC 获取对象时，容器可以检查其配置是否将缓存应用于给定类型，如果是，则创建一个带有缓存的基于接口的动态代理。该解决方案不会强迫您编写大量类似的代码，并且由于其在源代码中的可见性，因此比“真正的”AOP 更容易混淆。有一些这样的实现，但是您没有指定任何语言，所以我无法提供任何实现。
This is the question about should we use "real" AOP at all (by "real" I mean quantification and obliviousness, so that you can enable aspects globally and 100% transparently for the system). My opinion is to avoid that 100% transparent solutions every time you can. If you're at the development stage, it will be better to design your system in the way that don't force you to do tricks like AOP weaving at intermediate code level.
At the other hand, it will be quite disturbing to write caching concern for every component/interface you need, no matter how you'll do it. The most obvious way which came to my mind is to have a caching Decorator class for each cached class - one thing done many times.
So the path I will try to follow is to have an idea of AOP done using some IoC extension based on dynamic proxying. When fetching an object from IoC, container can check in its configuration should the cache be applied for given type and if so, create an interface-based dynamic proxy with caching. This solution is not forcing you to write a lot of similar code and is less confusing than "real" AOP by its visibility in the source code. There are some implementations like this, but you haven't specified any language, so I can't offer any.