EntLib PolicyInjection 的替换建议
我们目前使用企业库策略注入在我们的数据访问存储库上进行缓存，例如
公共接口 IClientStatusRepository { [CachingCallHandler(24, 0, 0)] IList GetAll(); var
clientStatusRepository = PolicyInjection.Wrap(new ClientStatusRepository());
这对我们来说很有效，因为它是声明性的，并且绝对不涉及配置文件。它也隐藏在我们自己的工厂模式后面，因此很容易替换。
我们已经开始寻找替代解决方案。寻找替代方案的主要原因是我们意识到需要更改当前使 ASP.NET 缓存内容过期的方式。另外，我们想引入分布式缓存（MemCached 或 AppFabric），并希望能够以声明方式从缓存中逐出对象
。任何人都可以提出一些他们在分布式缓存中理想使用的替代方案。如果解决方案需要每个类的配置，它将被自动排除。方面在代码中必须是声明性的。
谢谢克雷格
We currently use Enterprise Library Policy Injection for caching on our data access repository e.g.
public interface IClientStatusRepository
{
[CachingCallHandler(24, 0, 0)]
IList GetAll();
}
var clientStatusRepository = PolicyInjection.Wrap(new ClientStatusRepository());
This works well for us because its declarative and has absolutely has no configuration files involved. Its also hidden behind our own factory pattern so its easy to replace.
We have started looking at alternative solutions. The main reason for looking at alternatives is that we realised we needed to change the way it currently expires content from the asp.net cache. Also, we want to introduce a distributed cache (MemCached or AppFabric) and want to be able to evict objects declaratively from the Cache
Can anyone suggest some alternatives that they have used ideally with a distributed cache. If the solution requires config per class it will be automatically ruled out. The Aspects must be declarative in code.
Thanks
Craig
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
编写调用处理程序相当简单。您还可以使用缓存调用处理程序源作为示例。编写一个自定义调用处理程序来调用您想要使用的缓存系统。
请注意，这种缓存行为比看起来更难，而且 Entlib 处理程序犯了足够多的错误，我们将其拉出，而不是尝试为 Entlib 5 修复它。特别是，它会在 Web 项目中的用户之间“泄漏”结果，因为缓存是针对每个应用程序的。而面对任意类型的任意参数，智能地形成缓存键并不是一个容易的问题。
Writing call handlers is fairly straightforward. You also have the caching call handler source as an example. Write a custom call handler that calls the cache system you'd like to use.
Be aware that this caching behavior is harder than it looks, and the Entlib handler made enough mistakes that we pulled it rather than try to fix it for Entlib 5. In particular, it "leaks" results across users in a web project, since the cache is per application. And intelligently forming a cache key in the face of arbitrary parameters of arbitrary types is not an easy problem.