I don't have a question, I just want to present you my solution and want to discuss if this a good approach and what are its drawbacks.
I am using Archetype to compose my pages.
A page contains multiple modules (= ArchetypeFieldsetModel) which are stored as JSON in the database.
Every module calls a SurfaceController which renders the partial view:
@foreach (var module in Model.GetModules())
{
Html.RenderAction(module.Action, module.Surface, module);
}
I have created an "ArchetypeModule" for this purpose:
public class ArchetypeModule
{
public PageViewModel Page { get; set; }
public ArchetypeFieldsetModel Content { get; set; }
public string Action { get; set; }
public string Surface { get; set; }
public string CacheId { get; set; }
public List<ArchetypeFieldsetModel> GetList(string alias)
{
return Content.GetValue<ArchetypeModel>(alias).ToList();
}
public override string ToString()
{
return Surface + Action + CacheId;
}
}
For the OutputCache I do need VaryByParam for sure. This is an example SurfaceController I am using:
public class ExampleSurfaceController : SurfaceControllerBase
{
[ChildActionOnly]
[OutputCache(Duration = 60, VaryByParam = "model")]
public ActionResult Main(ArchetypeModule model)
{
// ...
}
}
As the ArchetypeModule is a complex object, its ToString() method is called when the OutputCache uses it. That's why I've overridden the method to provide a CacheId, which is calculated like this:
CacheId = JsonConvert.SerializeObject(fieldsetModel, new JsonSerializerSettings() { ReferenceLoopHandling = ReferenceLoopHandling.Ignore }).GetHashCode().ToString();
So I am serializing the complete JSON representation of the data which was entered in the backoffice and get the hash code from it.
What this does offer:
A unique (or not so unique for hash code ;-) ) representation of the model I am using
When the data is changed in the backoffice the CacheId will change too, therefore it will return the new (or previously cached) version of the partial.
So, how do you think does this approach work?
Do you see any drawbacks?
The first test worked well. I have to admit that I am pretty pleased with this solution right now, but not sure if it's "perfect" ;-)
Bye Tobi
Update 1
Looks like I have found the first drawback:
When you have an Archetype, let's say "News Overview" which does render news items from other nodes, you can add/modify/delete these news but the archetype properties itself don't change. In this case the CacheId stays the same too. Possible solution: Clear OutputCache when changes occur in the BackOffice!?
I assume you are expecting the caching to improve performance, but I am confused about where you expect that performance increase to come from.
It seems like you are first fetching the model using the Umbraco API (or so I assume), and then you are rendering the child action with that model. I would expect the rendering to happen very fast, and I would expect the fetching of the model to be slower. If the caching only happens after you have already fetched the model, I am not sure what performance gain you can expect.
Furthermore, I think MVC doesn't cache the result of the rendering process. I could be wrong, but I think it caches the model you return from your action method (as an ActionResult), and then supplies that cached model to the CSHTML file each time it renders the page (if your CSHTML has DateTime.Now.ToString(), you'd see that update even with a cached result). That means that you are effectively not caching anything.
I suppose the only thing that would be cached would be whatever happens in your "Main" action method. Supposing that function takes a lot of time (e.g., if you need to fetch a bunch of data based on your Archetype model), then I could see this caching being useful. Maybe that is the case as your update mentions a news overview... perhaps that would render info about child or picked news pages? I could see that taking some time to fetch, and so would be useful to cache.
Disclaimer: I may be misinterpreting what you are doing.
Thanks for your answer.
The JSON model is stored the same as every other property in Umbraco, in the XML content cache.
For your assumption that the partial view itself gets not cached, that's not true. On of the major benefits of OutputCaching (in my case Donut caching) is that the rendered view gets cached.
On the left side you can see the rendered page without OutputCaching (via Glimpse), on the right side with caching turned on. The rendering of the Page is faster because the partials are served from the cache. On complex pages you can save a few hundred ms here.
Looks like you are right about the partial being cached (just tested myself). I think I was confusing that with some form of caching in WebForms.
And you are right that Archetype property values are stored in the XML cache just like every other property. I was not questioning that.
I was just questioning what you were caching if you weren't caching the lookup of the Archetype model. I think I understand more clearly now that you have some logic in your action method that is taking some time. The approach you have outlined seems reasonable.
As far as invalidating the cache, I do that by implementing GetVaryByCustomString in my derived UmbracoApplication with a call to HttpResponse.RemoveOutputCacheItem (that works with the built-in output caching, but a different technique would probably be needed if you use MvcDonutCaching).
On a project I used MvcDonutCaching, I believe I invalidated the cache again in GetVaryByCustomString. Except, instead of invalidating the cache (I ran into some complication), I merely changed the cache key for any recently published page (I think I just stored a GUID that was associated with a page ID and that changed whenever a page was published).
For your purposes, you'd want to want to do something slightly more sophisticated. You could invalidate the cache for any page picking a changed node (if you are using the built in output caching). Or, you could generate a composite key for each page that is composed of a GUID associated with that page and the picked pages, perhaps hashed if you'd like to keep the keys small (for MvcDonutCaching). These GUID's would be changed anytime a node changes (e.g., on publish/delete/move events).
Could get complicated if you want to support an unlimited level of "picking", especially if there are circular references, but it's certainly possible.
As of late, I don't rely on output caching. Instead, I just cache things at the application level and invalidate those caches using a few utilities I've built. For example, I have one cache that invalidates media information based on the media ID. And I have another that invalidates a cache based on matching document types. Works pretty well as far as I've seen. An example would be caching a menu that is shown in the header of every page. You can simply cache the menu in a static variable, and clone that variable making the necessary modifications to ensure the menu marks the active page.
Using OutputCache with Archetype
Hi!
I don't have a question, I just want to present you my solution and want to discuss if this a good approach and what are its drawbacks.
I am using Archetype to compose my pages.
A page contains multiple modules (= ArchetypeFieldsetModel) which are stored as JSON in the database.
Every module calls a SurfaceController which renders the partial view:
I have created an "ArchetypeModule" for this purpose:
For the OutputCache I do need
VaryByParamfor sure. This is an example SurfaceController I am using:As the
ArchetypeModuleis a complex object, itsToString()method is called when the OutputCache uses it. That's why I've overridden the method to provide aCacheId, which is calculated like this:So I am serializing the complete JSON representation of the data which was entered in the backoffice and get the hash code from it.
What this does offer:
So, how do you think does this approach work?
Do you see any drawbacks?
The first test worked well. I have to admit that I am pretty pleased with this solution right now, but not sure if it's "perfect" ;-)
Bye Tobi
Update 1
Looks like I have found the first drawback:
When you have an Archetype, let's say "News Overview" which does render news items from other nodes, you can add/modify/delete these news but the archetype properties itself don't change. In this case the
CacheIdstays the same too.Possible solution: Clear OutputCache when changes occur in the BackOffice!?
I assume you are expecting the caching to improve performance, but I am confused about where you expect that performance increase to come from.
It seems like you are first fetching the model using the Umbraco API (or so I assume), and then you are rendering the child action with that model. I would expect the rendering to happen very fast, and I would expect the fetching of the model to be slower. If the caching only happens after you have already fetched the model, I am not sure what performance gain you can expect.
Furthermore, I think MVC doesn't cache the result of the rendering process. I could be wrong, but I think it caches the model you return from your action method (as an ActionResult), and then supplies that cached model to the CSHTML file each time it renders the page (if your CSHTML has DateTime.Now.ToString(), you'd see that update even with a cached result). That means that you are effectively not caching anything.
I suppose the only thing that would be cached would be whatever happens in your "Main" action method. Supposing that function takes a lot of time (e.g., if you need to fetch a bunch of data based on your Archetype model), then I could see this caching being useful. Maybe that is the case as your update mentions a news overview... perhaps that would render info about child or picked news pages? I could see that taking some time to fetch, and so would be useful to cache.
Disclaimer: I may be misinterpreting what you are doing.
Hi Nicholas.
Thanks for your answer. The JSON model is stored the same as every other property in Umbraco, in the XML content cache.
For your assumption that the partial view itself gets not cached, that's not true. On of the major benefits of OutputCaching (in my case Donut caching) is that the rendered view gets cached.
On the left side you can see the rendered page without OutputCaching (via Glimpse), on the right side with caching turned on. The rendering of the
Pageis faster because the partials are served from the cache. On complex pages you can save a few hundred ms here.Looks like you are right about the partial being cached (just tested myself). I think I was confusing that with some form of caching in WebForms.
And you are right that Archetype property values are stored in the XML cache just like every other property. I was not questioning that.
I was just questioning what you were caching if you weren't caching the lookup of the Archetype model. I think I understand more clearly now that you have some logic in your action method that is taking some time. The approach you have outlined seems reasonable.
As far as invalidating the cache, I do that by implementing GetVaryByCustomString in my derived UmbracoApplication with a call to HttpResponse.RemoveOutputCacheItem (that works with the built-in output caching, but a different technique would probably be needed if you use MvcDonutCaching).
On a project I used MvcDonutCaching, I believe I invalidated the cache again in GetVaryByCustomString. Except, instead of invalidating the cache (I ran into some complication), I merely changed the cache key for any recently published page (I think I just stored a GUID that was associated with a page ID and that changed whenever a page was published).
For your purposes, you'd want to want to do something slightly more sophisticated. You could invalidate the cache for any page picking a changed node (if you are using the built in output caching). Or, you could generate a composite key for each page that is composed of a GUID associated with that page and the picked pages, perhaps hashed if you'd like to keep the keys small (for MvcDonutCaching). These GUID's would be changed anytime a node changes (e.g., on publish/delete/move events).
Could get complicated if you want to support an unlimited level of "picking", especially if there are circular references, but it's certainly possible.
As of late, I don't rely on output caching. Instead, I just cache things at the application level and invalidate those caches using a few utilities I've built. For example, I have one cache that invalidates media information based on the media ID. And I have another that invalidates a cache based on matching document types. Works pretty well as far as I've seen. An example would be caching a menu that is shown in the header of every page. You can simply cache the menu in a static variable, and clone that variable making the necessary modifications to ensure the menu marks the active page.
is working on a reply...