I have an asp.net web forms application with established interfaces for acquiring and manipulating data. I'm at the point now where I'd like to start speeding up the application by caching the data of various interface operations.
I have a business logic layer, an data access layer, a web app layer.
The web app simply executes the implementations of the business logic interfaces. As such I can build implementations of those interfaces to use caching fairly easily.
What I don't understand is how I can invalidate cache data if the interfaces aren't built to include a reset fiction or something similar that would allow that interaction.
Say I use the application cache in my asp.net web forms implementation of a order retriever. I can include the cache key and the logic for establishing the cache directly in the classes implementation. But when I update the order, possibly using another service, I subsequently need to invalidate that cached data and get a new updated order the next time order retrieval occurs.
I'd like that my order retriever implementation could also store the logic for resetting itself, as it already contains the information of the cache type being used as well as the relevant caching keys and other details, but without updating the business logic interface to contain a reset function, which wouldn't make sense in any context other than that if a caching contact, I don't see how I can do this.
One idea I had was to decorate a class as Icacheable which has a reset function, and then in the application later, I can try and convert the order retriever implementation to an Icacheable. This seemed a bit hokey as the class might not implement it causing errors during translation.
I've been thinking about how best to design caching into my application for a while now so any ideas are appreciated.
CodePudding user response：
I'd like to start speeding up the application by caching the data of various interface operations.
Really? And you determined that pulling of data is the cause of the slow down?
I doubt that data issue would be the reasons for slow response.
And why would data need to be cached?
I mean, you bring up a customer reocrd, project, invoice or whatever? Well, now you pulled the data and displayed it. Why would that same data need say to be retrived again when the user moves on to work on say the next project, or different invoice. I fail to see any performance gains by this approach.
It possbile that some customer information is used over and over again, but really, that would amount to say one reocrd for that information, and how often to you need to pull and use that information again?
If you find the applcation runs great with 5 users, but then runs slow with 50 users? Then sure, that might suggest some optimizing and cache might help.
However, where and how and why is this same data being used again?
If the system runs slow with ONE user, then the path and solution you suggest probably is not the reason for such slow performance.
For example, say you fill out a grid view with some data. If you have to display more then 40 rows, then you might consider using a built-in data pager, and limit each page to 30 or 40 rows.
HOWEVER, built in paging for grid, or listviews etc.?
They are good for about 300 rows tops. If you are pulling more rows, then one would dump the data-pager, and build a custom pager that uses REAL database paging.
That way, to display those 30 rows, even if the table has 1 million rows will be instant. If a web page does not load instant right now, then this is more of design issue, and not trying to band-aid over the performance by introduction of caching.
What you REALLY need to do is figure out where large data pulls are occurring, and eliminate them.
Now, it is possbile you are involved in some kind of high speed and high rate of transactions, and thus one might want to consider caching of such data, but in most cases, your better off to optimize the data operations, make then very fast, and thus no need for such caching is thus required.
You not really provided suffuicnt details, and not reasons why say this data needed to be cached in the first place. Perahps one is moving the UI to more of a ajax interface, and those repeated and multiple web service calls thus needs the data over and over. In fact, this ajax apporach and needing to cache a complex set of talbes and data actually is often BETTER acheived by reduting your ajax calls on the page, and using state (such as session).
But, the session() should be kept small, and thus you back to square one:
That square one?
The data operations should not be slow anyway, and it not clear why they are slow. I would determine the reasons for the slow operations, and thus you eliminate the need for such caching anyway, right?
It is possible we are missing significant details here, and without such details, then you not really made a good case for introduction of some complex caching here, and you not noted how much data you are attempting to operate on for a given user, and their given task at a given instant in time.
The workflow of the interface should be in such a way that a lot of caching should not be required.
CodePudding user response：
I thought about this last night and consulted various guides online and came up w/ this approach that I think is fairly reasonable.
I create a cache layer to my application that implements the same interfaces the main application uses. It will also contain element specific cache class. In this case, I'll have a OrderCache class created. These specific elementcache classes take will take in an ICacheSource object and will have a GetAndCache() reset() and getKey() function. I define a ICacheSource as an object that implements GetAndCache() and Reset(). Yes they sound similar but one handles cache location and scope while the other handles details of the element being cashed. The cache layer implementation of the business logic will manage the calling of the business layer interfaces and also manage the use of the elementcache object for storage and retrieval.
On my application layer instead of creating business Layer interfaces I create the cache layer interfaces (where necessary). Thus the logic will remain the same but the execution of the logic will use the cached implementations when ever a pull is required.
I am able to manage the lifetime of the cached data by passing in the appropriate cacheScope object. If I want application level caching I pass in an applciationCacheService, if I want page level caching I pass in a viewStateCacheService.
If I need to reset the cache, as a result of a button click that triggers the update of the underlying data during a post back, the implementation that manages that data update will have a cache layer implementation as well which will also take in the specific element cache class it cares about and call the Reset() function when necessary.
I have the following question out to resolve the strange design flaw I see with this where I will require building an element cache class for every element needing cached yet each will really be almost the exact same except for the getkey function.
How to write multiple classes with same functions but different input