Истечение кэша NHibernate
Будет плохой идеей полностью удалить средство комментирования. Конечно, разработчики должны научиться писать код с минимальными комментариями, то есть писать самодокументированный код, но во многих случаях приходится объяснять, почему что-то делается так, как оно есть. Рассмотрим следующие случаи:
- новый разработчик может начать поддерживать код, а оригинальный разработчик исключил / из проекта
- изменение спецификации или требований рынка приводит к чему-то, что
-
Мой опыт подсказывает, что новые программисты, как правило, комментируют больше и как они развивают экспертизу, их код имеет тенденцию становиться самодокументирующимся и кратким. В общем, комментарии должны быть о ПОЧЕМУ, а не о том, КАК или ЧТО.
1 ответ
IMHO it's pointless to have an L2 cache if it needs to hit the DB anyway. That's precisely the entire point of caching, avoid hitting the DB as much as possible.
AFAIK there is no caching strategy implemented like the one you describe, but NHibernate L2 caches are entirely pluggable so you could implement it. However, I wouldn't, for the reasons I mentioned above.
Getting outdated data is only an issue if there are other apps or other DALs hitting the same DB besides NHibernate. If that's the case, you could use the SysCache2 implementation, which internally uses SqlCacheDependencies to invalidate cache regions when data in the underlying table changes.
If it's a single app running in a farm, use the Velocity provider.
If there's only one NHibernate app instance hitting the DB, any cache strategy will do and you don't have to worry about getting outdated data.
See also: