CODEWITHSUNDEEP
asp.net-mvccaching.net-4.0repository
mare
mare

Reputation: 13083

Caching repository object or data results selectively

I've been looking into implementing caching at Repository level using the .NET 4.0 Caching features or via a third party abstraction interface like this one and I've just run into an issue where I will have to support two use cases.

My application might be split in multiple areas, for instance the Admin area and the User frontend (website frontend). I don't want any caching to take place in the Admin area, Admins should always have the latest refreshed data displayed to them.

now, do I have to refactor all my repository methods to take in a parameter whether to return the cached results or not? Are there any other options?

Upvotes: 0

Views: 350

Answers (2)

Aliostad
Aliostad

Reputation: 81660

There are various levels of caching that can be applied since you are using ASP.NET. I would not go about re-inventing the wheel if we have it already there.

We have:

  • ASP.NET server caching
  • ASP.NET output caching on server (using [OutputCache] on the action)
  • ASP.NET output caching on client (using [OutputCache] on the action)

Entity Framework or other ORMs can do the caching as well. So I would say use what is already there until you are sure it does not do what you need.

UPDATE

If you have to do it at repository, I would suggest use Dependency injection features to inject the right repository (one with caching or no-caching)

Upvotes: 0

Darin Dimitrov
Darin Dimitrov

Reputation: 1038940

You could do the caching at the controller level, not at the repositories. This way in the admin area controllers you will always query the repository to get fresh data and in the others you will cache the results. If you absolutely need to do the caching of the objects at the repository layer you need an additional parameter to indicate whether the call is being made from the Admin area or not. Or you could also use a DI framework such as NInject which allows you to pass parameters from the HttpContext to dependencies that are allocated per request lifetime. So you could inject the area RouteData parameter to your repository's constructor.

Upvotes: 1

Related Questions