This project is read-only.

Cached PostSharp Aspect vs OutputCache

May 26, 2010 at 10:33 AM

Can you tell me why Cached attribute is introduced in WCHM? There is good working and well known OutputCache attribute.

May 26, 2010 at 11:41 AM

Because it's a pluggable caching infrastructure - we swap it between HTTPCache / Velocity / MemCache - the cached attribute also gives us finer grained control over where the cache data sits, when it expires etc.

May 26, 2010 at 11:56 AM

My question should be rather: should/can they be use in conjunction or not? OutputCache is a little bit more "complicated" (user side cache, sql and header cache triggers), here we only have time duration.

May 26, 2010 at 5:00 PM
The OutputCache attribute covers a couple of different things but the main issue is that it doesn't easily support donut caching - it caches the page in it's entirety. If that's what you need then by all means crack on and use it. However for the kind of apps I generally end up working on it's not acceptable because they normal include some level of personalised content (e.g. shopping cart on an e-commerce site).

Have a look at my blog posts for more info on the caching approach used in WCHM:

As you'll gather it's important to note that the CachedAttribute is doing something completely different to the OutputCache attribute. the CachedAttribute is (in this case) caching the built up viewmodel for the page, whereas the OutputCache attribute caches the rendered content for the page - it's a level up in the pipeline. When OutputCache is used correctly, the request for the URL can potentially be served without hitting your app code at all, whereas with CachedAttribute your controller will always be invoked.

Also, should you feel the need it would be relatively easy to add more functionality to the CachedAttribute. Actually, all it's doing is providing a shortcut for using the ICachingService, which is the real limiting factor. We kept it basic because it makes it easier to switch cache providers out (e.g. standard ASP.NET vs Velocity, memcached, etc.)

Hope this makes sense.

Cheers,
Jon

On 26 May 2010 11:56, awattar <notifications@codeplex.com> wrote:

From: awattar

My question should be rather: should/can they be use in conjunction or not? OutputCache is a little bit more "complicated" (user side cache, sql and header cache triggers), here we only have time duration.

Read the full discussion online.

To add a post to this discussion, reply to this email (whocanhelpme@discussions.codeplex.com)

To start a new discussion for this project, email whocanhelpme@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


May 26, 2010 at 8:17 PM
Ok. It does make sense. I'm trying to build my project on basis of WCHM. I've read every line of code, transform it in use in my project. The only problems i've found were http://whocanhelpme.codeplex.com/WorkItem/View.aspx?WorkItemId=10886 and Cached attribute. If you can help me with FluentHtml and xVal i'll be appreciated.

Mike

2010/5/26 jon_george1 <notifications@codeplex.com>

From: jon_george1

The OutputCache attribute covers a couple of different things but the main issue is that it doesn't easily support donut caching - it caches the page in it's entirety. If that's what you need then by all means crack on and use it. However for the kind of apps I generally end up working on it's not acceptable because they normal include some level of personalised content (e.g. shopping cart on an e-commerce site).

Have a look at my blog posts for more info on the caching approach used in WCHM:

As you'll gather it's important to note that the CachedAttribute is doing something completely different to the OutputCache attribute. the CachedAttribute is (in this case) caching the built up viewmodel for the page, whereas the OutputCache attribute caches the rendered content for the page - it's a level up in the pipeline. When OutputCache is used correctly, the request for the URL can potentially be served without hitting your app code at all, whereas with CachedAttribute your controller will always be invoked.

Also, should you feel the need it would be relatively easy to add more functionality to the CachedAttribute. Actually, all it's doing is providing a shortcut for using the ICachingService, which is the real limiting factor. We kept it basic because it makes it easier to switch cache providers out (e.g. standard ASP.NET vs Velocity, memcached, etc.)

Hope this makes sense.

Cheers,
Jon

On 26 May 2010 11:56, awattar <notifications@codeplex.com> wrote:

From: awattar

My question should be rather: should/can they be use in conjunction or not? OutputCache is a little bit more "complicated" (user side cache, sql and header cache triggers), here we only have time duration.

Read the full discussion online.

To add a post to this discussion, reply to this email (whocanhelpme@discussions.codeplex.com)

To start a new discussion for this project, email whocanhelpme@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Read the full discussion online.

To add a post to this discussion, reply to this email (whocanhelpme@discussions.codeplex.com)

To start a new discussion for this project, email whocanhelpme@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


May 27, 2010 at 4:39 PM

There is one more thing - you wrote that :

Spark also contains something called the ValueHolder which effectively allows you to defer the gathering of model data until it’s needed. This means that rather than build up the model for every request, only to pass it to a view which doesn’t need it because it’s entirely output cached, you can build your model using ValueHolder objects containing lambda functions that will only be executed if the data is needed. This seems like an interesting approach, but it’s not one I explored in detail because the caching we’d already implemented on the controllers made it less relevant.

http://jonathangeorge.co.uk/2009/11/03/optimising-an-asp-net-mvc-web-site-part-4-output-caching-in-the-brave-new-world-of-mvc/

I think that ValueHolder will hit for data (and get new one) only when the catching key was changed but Cached Attribute will serve always the same data for specific amount of time. So in my opinion is only useful for semi-dynamic content like main page with list of products on ecommerce site. Am i right?

 

Mike

May 27, 2010 at 9:21 PM
Possibly, although I'm not 100% sure I understand what you mean. Are you saying that you think caching the ViewModel is only useful for semi-dynamic content? I think it would be easy to extend the pattern to only cache sections of the ViewModel and have the remainder populated per request...

Don't get too hung up on the fact that, at the moment, the CachedAttribute only supports time based cache expiration. Firstly, it's pretty straightforward to modify it to do other forms of expiration. Secondly, aspects like this tend to follow the 80/20 rule - so there will be cases where it's just easier to write the caching code yourself rather than use the aspect.

The only other thing I'd say is that I'm not a massive fan of the ValueHolder as it feels wrong to allow view implementation details to seep down into the controllers, but I'd certainly be interested in your reasoning if you decide to go with the ValueHolder approach.

Cheers
Jon

On 27 May 2010 16:39, awattar <notifications@codeplex.com> wrote:

From: awattar

There is one more thing - you wrote that :

Spark also contains something called the ValueHolder which effectively allows you to defer the gathering of model data until it’s needed. This means that rather than build up the model for every request, only to pass it to a view which doesn’t need it because it’s entirely output cached, you can build your model using ValueHolder objects containing lambda functions that will only be executed if the data is needed. This seems like an interesting approach, but it’s not one I explored in detail because the caching we’d already implemented on the controllers made it less relevant.

I think that ValueHolder will hit for data (and get new one) only when the catching key was changed but Cached Attribute will serve always the same data for specific amount of time. So in my opinion is only useful for semi-dynamic content like main page with list of products on ecommerce site. Am i right?

 

Mike

Read the full discussion online.

To add a post to this discussion, reply to this email (whocanhelpme@discussions.codeplex.com)

To start a new discussion for this project, email whocanhelpme@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


May 27, 2010 at 10:09 PM
That's completely true. I'm only looking for "product" that is on the market to have at least some form of support. I'm always afraid of extending frameworks too much so i can loose ease of upgrading them when new version arrives. I'm not saying that caching the ViewModel is only useful for semi-dynamic content - i'm only saying that is now with this set of attributes.

Mike

2010/5/27 jon_george1 <notifications@codeplex.com>

From: jon_george1

Possibly, although I'm not 100% sure I understand what you mean. Are you saying that you think caching the ViewModel is only useful for semi-dynamic content? I think it would be easy to extend the pattern to only cache sections of the ViewModel and have the remainder populated per request...

Don't get too hung up on the fact that, at the moment, the CachedAttribute only supports time based cache expiration. Firstly, it's pretty straightforward to modify it to do other forms of expiration. Secondly, aspects like this tend to follow the 80/20 rule - so there will be cases where it's just easier to write the caching code yourself rather than use the aspect.

The only other thing I'd say is that I'm not a massive fan of the ValueHolder as it feels wrong to allow view implementation details to seep down into the controllers, but I'd certainly be interested in your reasoning if you decide to go with the ValueHolder approach.

Cheers
Jon

On 27 May 2010 16:39, awattar <notifications@codeplex.com> wrote:

From: awattar

There is one more thing - you wrote that :

Spark also contains something called the ValueHolder which effectively allows you to defer the gathering of model data until it’s needed. This means that rather than build up the model for every request, only to pass it to a view which doesn’t need it because it’s entirely output cached, you can build your model using ValueHolder objects containing lambda functions that will only be executed if the data is needed. This seems like an interesting approach, but it’s not one I explored in detail because the caching we’d already implemented on the controllers made it less relevant.

I think that ValueHolder will hit for data (and get new one) only when the catching key was changed but Cached Attribute will serve always the same data for specific amount of time. So in my opinion is only useful for semi-dynamic content like main page with list of products on ecommerce site. Am i right?

 

Mike

Read the full discussion online.

To add a post to this discussion, reply to this email (whocanhelpme@discussions.codeplex.com)

To start a new discussion for this project, email whocanhelpme@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Read the full discussion online.

To add a post to this discussion, reply to this email (whocanhelpme@discussions.codeplex.com)

To start a new discussion for this project, email whocanhelpme@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com