So intead of using ExportMetadata attribute, why not just extend the interface instead?
views:
100answers:
2
+1
A:
Good question. I think that extending the interface is the correct thing to do whenever you have the option. It much better communicates intent.
However, we may need more fine-grained control over interfaces that we don't own. In those cases we can use ExportMetadata as a substitute.
In my opinion you should only use ExportMetadata when there is no other option available to you.
Mark Seemann
2010-09-20 11:10:35
+4
A:
if you import Lazy<> stuff via MEF you can look into the metadata without instantiate your object.
blindmeis
2010-09-20 13:27:30
This is the answer. Metadata can be read without actually instantiating the object. This can be pretty useful sometimes...
Tim
2010-09-20 14:21:39
So? Instead you instantiate a bunch of `Lazy<T>` objects. Sounds like you are sacrificing premature micro-optimization for clean design. Not a good trade-off IMO.
Mark Seemann
2010-09-20 14:43:07
@Mark Visual Studio has catalogs that can save all the metadata information for parts, and later the catalog can be queried without having to load the assemblies. This means that using Lazy<T> not only avoids instantiating the object, but avoids loading the assembly entirely. Since the metadata is used to choose which part of many should be activated, this helps the performance significantly for Visual Studio. Smaller systems usually don't need to worry about this kind of thing and in those cases adding the information to the interface instead of the MEF metadata can be a better choice.
Daniel Plaisted
2010-09-20 19:21:57
+1 @daniel plaisted
blindmeis
2010-09-20 20:14:06
That metadata in those catalogs doesn't get there magically. It gets there because attributes are queried via reflection. When you query attributes, you interact with Attribute instances, so objects still end up being instantiated - not to mention the `Lazy<T>` instances and the metadata instances when you query the metadata. It *may* be slightly faster, but I still consider it a micro-optimization... and I don't buy the VS example: VS 2010 takes significantly more time to start than VS 2008.
Mark Seemann
2010-09-21 13:56:26
Mark, the metadata is serialized into the catalog at build time too. VS startup performance is a very complex thing, and Daniel is the one who has the numbers.
Nicholas Blumhardt
2010-09-21 21:54:53
VS2010 was a complete re-write, so its start time is hardly evidence. One project I'm working on, the interface is not in my assembly so metadata is perfect.
Tim
2010-09-21 23:42:49