I'm looking for a good way of handling near-static data in NHibernate - where near-static data is config / lookup data that is usually changed (rarely) through an admin part of the application.
Since this data changes infreque开发者_运维问答ntly and can be quite big - and supposedly "immutable" to most of the application, it seems silly to load it into the NHibernate session to be checked for flushing etc.
Off the top of my head I can think of a few possible solutions:
Using Evict after loading the data in the normal parts of the application to exclude it from change tracking / flushing. Relying on 2nd level cache to make retrieval fast.
Creating my own cache for the normal part of the application and storing the detached entities there, updating the cache upon writes from admin part.
Using a second session with FlushMode.Never for loading the data in the normal part of the application.
Using Criterias / QueryOver in NH 3.0 to retrieve the data as read-only.
???
It doesn't seems like a rather common problem for most applications, what is the best way to handle it?
i would open a seperate session and load the needed config data when needed and close the session afterwards. if the data is used very often, it can be cached somewhere or keep the seperate session open to facilitate first level cache.
I would use a two pronged approach. First of all you can use the 2nd level cache to allow all sessions to access the same instance of the data. Secondly I would use an IStatelessSession
to retrieve it. This will prevent the session from actually tracking the object.
精彩评论