我有什么理由不应该在 nHibernate 中缓存吗？
我刚刚发现了流畅的 nHibernate 中 Cache.ReadWrite() 的乐趣，并且一直在使用 nhprof 广泛分析结果。
看上去很有用，但又显得有点欺骗性。我不想想要缓存查询中非常频繁使用的对象是否有任何特殊原因？我的意思是，我必须假设我不应该只是用缓存属性来装饰每个映射......或者我应该吗？
I've just discovered the joy of Cache.ReadWrite() in fluent nHibernate, and have been analyzing the results with nhprof extensively.
It seems to be quite useful, but that seems a bit deceptive. Is there any particular reason I wouldn't want to cache a very frequently used object from a query? I mean, I have to presume I should not just go around decorating every single Mapping with a Cache property ... or should I?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
像往常一样，这取决于:)
如果某些内容有可能被不使用二级缓存的后台进程更新，或者直接在数据库中更改，则缓存将导致问题。
不经常访问的实体也可能不适合二级缓存，因为它们只会占用空间。
此外，如果您将集合映射为反向，您可能会看到一些奇怪的情况 - 二级缓存不会正确拾取更改，并且您需要手动逐出集合。
正如 sJhonny 下面指出的，如果您有一个网络场场景（或者您的应用程序在多个服务器上运行的任何场景），您将需要使用分布式缓存（如 memcached），而不是内置的 ASP.net 缓存。
As usual, it depends :)
If something has potential to be updated by background processes that don't use the second level cache, or changed directly in the database, caching will cause problems.
Entities that are infrequently accessed may not be good candidates for second level caching either, as they will just take up space.
Also, you may see some weirdness if you have collections mapped as Inverse - the changes will not be picked up by the second level cache correctly and you'll need to manually evict the collection.
As sJhonny points out below, if you have a web farm scenario (or any where your app is running on several servers) you'll need to use a distributed cache (like memcached) instead of the built in ASP.net cache.