At work, over time we have introduced the need to find types in the app domain. This is to eliminate configuration in favor of convention and declaration.. Each of these needs came up independently, and each do it their own ways. That annoys me. it needs to be refactored so that the app domain is crawled only once, and all can share the results.
My latest personal project has the same needs. I created TypeCache to solve the problem.
You tell the cache what types to look for, and also what attributes to look for. Those types are loaded and stored, and the TypeCache is added to the unity container as a singleton. Anything that needs it simply accepts it as a dependency, and away it goes.
I’m still working on the interface. I’m not a huge fan of the load method, but I didn’t want the constructor to initiate the crawl. So, while the details may change, the result is what I need. One thing that will have to change: inject the crawler rather than have it always do the full app domain. (Inspired by MEF catalogs).
The methods return types, usually by name (a custom attribute). Then, I use Unity to construct an instance of the type. It’s pretty sweet.
I have been somewhat familiar with MEF for a long time. Today I took the time to do my homework on it, wondering if I should have used it instead of inventing the type cache. So far, my answer is no, but I leave the issue open to debate. I want to use Unity for composition, not MEF. If anything, I just want MEF to find the types. I didn’t see anything that would reveal the type. (It can return a subclass of Lazy<T> which may contain the type information… don’t know without trying). For now, I’m going to stick to the TypeCache.