In practice, MEF (3): only export class members

Based on the introduction in the previous two articles, I believe you will understand the practical value of MEF. We also discussed import and export in the previous article. for export and import, we will go deeper today. Well, it's just a little bit deeper and it won't be very difficult. Please rest assured that, if you think reading the article is boring, you may wish to read it while drinking milk.

In the previous article, we export the entire type (entire class). However, sometimes we may consider exporting only some members of the class, such as an attribute or a field.

Let's talk less about the theory, so that everyone can't drink milk. Let's just serve it directly. For ease of test, the following example writes all components in the current Assembly, that is, in the same project, and then uses AssemblyCatalog for search.

First, define a public interface IWork.

Then we use two classes to implement this interface.

 

Then, we define another general class, which contains two attributes and return the instances of the FirstWork class and SecondWork class respectively.

The ExportAttribute feature is only attached to the WorkFirst and WorkSecond attributes. The Works class only exports these two attributes.

Then we assembled and called the exported parts.

Then run the example to obtain the result as shown in:

Many people like to directly Ctrl + C others' code when learning programming. This is a rather bad way of learning, so I have made all the code. Haha.

I used Lazy <T> to import the field declaration beforehand, but found that the object cannot be created. The possible reason is that we export a part of the class, the Works class needs to be instantiated when assembling components during internal runtime, because if the Works object is not instantiated, The WorkFirst and WorkSecond attributes will not be exported. Maybe this is the cause.

At this time, you may wonder what to do if I define a method in the Works class?

Now that you have thought of something to wait for, you can try it now. Let's change the code of the Works class and export a ViewWork method.

Why does the protocol type use Func <TResult>?

The imported protocol name and protocol type must match the export. Otherwise, the Import fails. This is like matching your words and deeds. Otherwise, your sister will not care about you.

After the assembly code is completed, we test the method for calling the import.

Run the command to check whether there are any results.

But at last, paste the complete code.