NOTE: This read is the abstract of the main article.Here is the main article
Domain Object Caching
Caching greatly improves application performance because it reduces expensive trips to the database. But, if you want to use caching in your application, you must decide what to cache and where to put your caching code. The answer is simple. Cache your domain objects and put caching code inside your persistence classes. Domain objects are central to any application and represent its core data and business validation rules. And, while domain objects may keep some read-only data, most of the data is transactional and changes frequently. Therefore, you cannot simply keep domain objects as “global variables” for the entirety of your application because the data will change in the database and your domain objects will become stale, thereby causing data integrity problems. You’ll have to use a proper caching solution for this. And, your options are ASP.NET Cache, Caching Application Block in Microsoft Enterprise Library, or some commercial solution like NCache from Alachisoft. Personally, I would advise against using ASP.NET Cache since it forces you to cache from presentation layer (ASP.NET pages) which is bad. The best place to embed caching in your application is your domain objects persistence classes.
Domain objects form the backbone of any application. They capture data model from the database and also the business rules that apply to this data. It is very typical for most subsystems of an application to rely on these common domain objects. And, usually applications spend most of their time in either loading or saving these domain objects to the database. The actual “processing time” of these objects is very small specially for N-Tier applications where each “user request” is very short.
The solution is an extension of an existing design pattern called Domain Objects Persistence Pattern for .NET. That pattern already achieves the goal of separating domain objects from persistence code and from the rest of the application as well. This double-decoupling provides a great deal of flexibility in the design. The domain objects and the rest of the application is totally unaffected whether the data is coming from a relational database or any other source (e.g. XML, flat files, or Active Directory/LDAP).
Therefore, the best place to embed caching code is in the persistence classes. This ensures that no matter which part of the application issues the load or save call to domain objects, caching is appropriately referenced first. This also hides all the caching code from rest of the application and lets you replace it with something else should you choose to do so.
Creating Cache Keys
Most cache systems provide you with a string-based key. At the same time, the data that you cache consists of various different classes (“Customers”, “Employees”, “Orders”, etc.). In this situation, an EmployeeId of 1000 may conflict with an OrderId of 1000 if you keys do not contain any type information. Therefore, you need to store some type information as part of the key as well. Below are some suggested key structures. You can make up your own based on the same principles.
1. Keys for individual objects: If you’re only storing individual objects, you can make up your keys as following:
a. “Customers:PK:1000”. This means Customers object with primary key of 1000.
2. Keys for related objects:For each individual object, you may also want to keep related objects so you can easily find them. Here are keys for that:
3. Keys for query results:Sometime, you run queries that return a collection of objects. And, these queries may also take different run-time parameters each time. You want to store these query results so the next time you don’t have to run the query. Here are the keys for that. Please note that these keys also include run-time parameter values:
. “Employees:QRY:FindByTitleAndAge:Manager:40”.This represents a query in “Employees” class called “FindByTitleAndAge” which takes two run-time parameters. The first parameter is “Title” and second is “Age”. And, their runtime parameter values are specified.
Using the Domain Objects Caching Pattern, we have demonstrated how you should embed caching code into your persistence classes. And, we’ve covered the most commonly used situations of Load, Queries, and Relationships with respect to caching. This should give you a good starting point to determine how you should use caching in your application