Implementing ICachedComposablePartCatalog

Dec 8, 2008 at 3:38 PM
I've implemented two custom part catalogs and would now like to give them cache capabilties so they follow the same functionality which have been provided by the catalogs included in the framework itself. Looking at the implementations of ICachedComposablePartCatalog in the shipped catalogs I see that they all rely (heavily) on cache helpers (AttributedComposablePartCatalogSite, ReflectionCacheServices and so on) which are all marked as internal. So a couple of questions about implementing the ICachedComposablePartCatalog interface.

1) Whats the thoughts around implementing the ICachedComposablePartCatalog interface in custom catalogs? How do you recommend people do this?
2) What are the reasons for all of the helpers being internal? Do you plan on making them public so the caching mechanics doesn't have to be reinvented for each catalog implementor?

Dec 8, 2008 at 10:08 PM
Caching of catalogs is a pretty advanced feature, and is probably one of the most fluid part of our API.

In order to support caching, any catalog needs to first implement a caching site - its implementation can be shared among multiple catalog types. The responsibility of the site is to "persist" part definitions into dictionaries and back. This is something that is heavily dependent on a specific programming model (i.e. specific implementation of primitives). Dictionaries may contain primitive types, enums, strings, typeofs, and enumerables and dictionaries thereof.
Then - at least today - the catalog needs to implement ICahedComposablepartCatalog as well as supply a constructor with a special shape - the former will be used to write the cache, the latter is to read from the cache. Both functions will ultimately write or read any relevant caching information to/from dictionaries (same limitations apply).

The implementation we provide today uses the - indeed internal - class (AttributedComposablePartCatalogSite), but I am surprised that you would care about that. the only reason you would ever need to-implement its functionality is when you want to create a new catalog that is based on our defualt programming model. Given that we provide a catalog that wraps any number of types, I don't see why you would ever want that - all you need is to aggregate several AttributedTypesPartCatalogs, and you should be set. That's our recommendation anyway, and you would pretty much get the caching for free. Would that work for you?

Dec 8, 2008 at 10:20 PM
I'm not looking to use scenario-specific cache logic per say, what I have done is write two new catalogs (derived from ComposablePartCatalog) and I would like for them to have caching support, just like the shipped catalogs. I want to make sure they offer the same external (API) functionality as the shipped catalogs, making them interchangable (substitution). So I was hoping there was a more generic approach to caching, provided by the framework so that it wouldn't have to be reinvented each time a new catalog was derived.




From: notifications@codeplex.com
To: andreas@selfinflicted.org
Date: Mon, 8 Dec 2008 15:08:18 -0800
Subject: Re: Implementing ICachedComposablePartCatalog [MEF:41777]


.ExternalClass {font-family:Verdana;font-size:0.75em;} .ExternalClass #EC_ThreadNotificationFooter {border-top:1px solid #ccc;color:gray;} .ExternalClass #EC_ThreadNotificationPostBody {margin-bottom:2em;} .ExternalClass {font-family:Verdana;font-size:0.75em;} .ExternalClass #EC_ThreadNotificationFooter {color:gray;border-top:1px solid #ccc;} .ExternalClass #EC_ThreadNotificationPostBody {margin-bottom:2em;} From: olegl
Caching of catalogs is a pretty advanced feature, and is probably one of the most fluid part of our API.

In order to support caching, any catalog needs to first implement a caching site - its implementation can be shared among multiple catalog types. The responsibility of the site is to "persist" part definitions into dictionaries and back. This is something that is heavily dependent on a specific programming model (i.e. specific implementation of primitives). Dictionaries may contain primitive types, enums, strings, typeofs, and enumerables and dictionaries thereof.
Then - at least today - the catalog needs to implement ICahedComposablepartCatalog as well as supply a constructor with a special shape - the former will be used to write the cache, the latter is to read from the cache. Both functions will ultimately write or read any relevant caching information to/from dictionaries (same limitations apply).

The implementation we provide today uses the - indeed internal - class (AttributedComposablePartCatalogSite), but I am surprised that you would care about that. the only reason you would ever need to-implement its functionality is when you want to create a new catalog that is based on our defualt programming model. Given that we provide a catalog that wraps any number of types, I don't see why you would ever want that - all you need is to aggregate several AttributedTypesPartCatalogs, and you should be set. That's our recommendation anyway, and you would pretty much get the caching for free. Would that work for you?

Read the full discussion online.
To add a post to this discussion, reply to this email (MEF@discussions.codeplex.com)
To start a new discussion for this project, email MEF@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