Different overloads of Import/Export

Nov 27, 2008 at 1:48 PM
Are there any guidelines for when to use the different overloads of these attributes? Are they used to be able to support the notation of scopes? For exampel the Import(typeof(...)) will import all parts which implements the provided type, while Import(".....") could be used to import the subset of parts which has specifically given name?

Then again named imports/exports could be seen as providing a contract without any implementation and then it would be a waste to provide an empty interface just to give them a shared contract. The only thing they would need to have in common is to be able to be cast to the type of the property to which they are imported.

Thanks for any information :-)
Nov 27, 2008 at 1:58 PM
Under the hood the typeof(IMyContract) is always translated into a string name. The main reason for this is to be able to use MEF in dynamic languages as well as with statically typed languages. So if you have a contract "MyNameSpace.IMyContract" then these two are equivalent:

[Import(typeof(IMyContract))]

[Import("MyNameSpace.IMyContract")]

Makes sense?

M.

On Thu, Nov 27, 2008 at 15:48, TheCodeJunkie <notifications@codeplex.com> wrote:

From: TheCodeJunkie

Are there any guidelines for when to use the different overloads of these attributes? Are they used to be able to support the notation of scopes? For exampel the Import(typeof(...)) will import all parts which implements the provided type, while Import(".....") could be used to import the subset of parts which has specifically given name?

Then again named imports/exports could be seen as providing a contract without any implementation and then it would be a waste to provide an empty interface just to give them a shared contract. The only thing they would need to have in common is to be able to be cast to the type of the property to which they are imported.

Thanks for any information :-)

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 or change your settings 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




--
Magnus Mårtensson
Senior Consultant - Scrum Master - MCSD, MCTS
Dotway AB

Tel: +46 (768) 51 00 36

http://blog.noop.se/
Nov 27, 2008 at 2:06 PM
Well the examples use both overloads withing the same exampel and in many cases they have the actuall contract defined as

ISomeContract

but use "Namespace.SomeContract", i.e without the I-notation.. so there doesnt appear to be a 1-1 relationship btween the two
Nov 27, 2008 at 5:12 PM
Edited Nov 27, 2008 at 5:15 PM

In general you should use the type overloads wherever possible.

One place where using a string overload are used is for property exports. When you have a type that is sealed such as our primitive types. For example if you are exporting a Timeout value which is a long. You can’t inherit from long, so you might do the following

public class Config {
  [Export(“Timeout”)]
  public long Timeout {get;set;}
}

You might have multiple exports of the same primitive type such as a Buffer size.

public class Config {
  [Export(“Timeout”)]
  public long Timeout {get;set;}

  [Export(“BufferSize”)]
  public long BufferSize {get;set;}
}

The other advantage of the string would be if you want to use a moniker to get a specific export even if it is not a primitive. For example a set of different views.

[Export(“MainView”)]
public UserControl MainView {get;set;}

[Export(“UserView”)]
public UserControl UserView {get;set;}

Another place would be for exporting methods.

[Export(“SaveCommand”)]
public void Save() {..}

[Export(“OpenCommand”)]
public void Open() {..}

Regards
Glenn

From: TheCodeJunkie [mailto:notifications@codeplex.com]
Sent: Thursday, November 27, 2008 7:07 AM
To: Glenn Block
Subject: Re: Different overloads of Import/Export [MEF:40946]

 

From: TheCodeJunkie

Well the examples use both overloads withing the same exampel and in many cases they have the actuall contract defined as

ISomeContract

but use "Namespace.SomeContract", i.e without the I-notation.. so there doesnt appear to be a 1-1 relationship btween the two

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 or change your settings 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

Nov 28, 2008 at 1:04 PM
@gblock,
Just to sum this up and to see if I understood you correctly. The "best-practice" for using the string overload is for when you

* Import/Export sealed types
* When you want to Import/Export a selection of a shared type

correct?
Dec 1, 2008 at 9:55 PM
Here's the gist of the story with contracts:
A contract is a name, nothing more, nothing less. If you use a type in your import/export/GetExportXXX notation, the name is inferred (it's basically full type name, but you can change it through the use of the ContractType on the type).
A contract can be narrower that a type (not just a string, but a 'ConnectionString') or wider than a type (e.g "SerializableConfigurationItem", which denotes an item of any type which the application configuration system is expected to serialize). You simply can't use typed contracts for those.
We do encourage you to use typed imports/exports as much as feasible, but sometimes this is not possible or desirable - if the semantics of the contract and the type don't precisely match. In other words, you should alsways ask yourself whether the typed contract would do the job - and whether it would do the job right. If not, purely named contracts are your friend.
Dec 2, 2008 at 6:13 AM
Awesome! Thanks gblock and olegl!