CSLA 3.5/SQL Server 2005/.Net 3.5
I am using CSLA NameValueListBase object to store values, used to populate drop down list. If user changes list value using my application i can invalidate this list, so next access to NVL will go to SQL Server to populate the list.
There is a server process running and updates the table data, and application is not aware that data has changed. How do i invalidate my NVL in this scenario.
1. Cache only for a certain time period (timespan) - then reload data.
Ex store the timestamp in static variable with the list and check for expiry in static factory method.
2. If this is not sufficient then remove cache - always load data from database.
I'd prefer to keep the cache/nocache code in the NVL - the client (or UI) using the list should not be bothered with this.
Basically what Jonny said.
I personally though used to have the BO do the caching, but I've found when I reuse the BOs in another application often the caching requirements are different.
For example take an Ad that's both on a public site and available for viewing in a preview tool. The previewer tool wants to always see the current data (to verify if the mistakes have been corrected, for example). However the public site should cache the Ad. Mostly its unchanged, so you want caching, not always hit the database.
And for the preview tool you _could_ always call InvalidateCache first to make sure you get a fresh reload or create separate factory method for direct access that just calls InvalidateCache and Get...
If it something like a memcache server you're using to cache, that would invalidate the cache for the public site as well. Personally both seem to be less maintainable than simply having the application worry about whether it wants caching or not.
Whether you cache or not is not a business decision at all; its a technical decision developers make based on the needs of the particular application. The business layer is fine for business requirements, but the business directly care about caching. They care about either high performance or accurate data.
Copyright (c) Marimer LLC