Sharing of a composed container?

Nov 28, 2008 at 5:16 AM
Hi,

Suppose I wanted/needed to be able to access the container I have composed across several assemblies so that they too can use it, what would be the recommened approach.  One of the examples I have noticed adds the container to itself and then defines an import to access it.  But what if I want access to the container from types that are created outside of the container where an import wouldn't work (or from a static class), instead of having an import defined I would make a call to one of the Get methods of the container.

Any thoughts or ideas?

Thanks
Trent
Nov 28, 2008 at 7:05 AM
This is a sticky problem!

If you have a part somewhere that only knows it is a part and not where the container is located then you are in theory screwed! You might not have a reference to the code that spawned the container.

In this case you need to resort to some kind of global service that you can reach out to from anywhere in you application. But it is always better to create your stuff thorough the container and resolver.

Any time you step out of that circle of shared state if you will you end up in messy situations where you have to make specific allowances.

IMHO.

M.

On Fri, Nov 28, 2008 at 07:16, tgc <notifications@codeplex.com> wrote:

From: tgc

Hi,

Suppose I wanted/needed to be able to access the container I have composed across several assemblies so that they too can use it, what would be the recommened approach. One of the examples I have noticed adds the container to itself and then defines an import to access it. But what if I want access to the container from types that are created outside of the container where an import wouldn't work (or from a static class), instead of having an import defined I would make a call to one of the Get methods of the container.

Any thoughts or ideas?

Thanks
Trent

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/
Dec 2, 2008 at 7:21 PM
Trent, what are you trying to achieve here? We generally discourage the part authors to access the container even via importing, and it restricts their reuse. Sounds like that's not what you want either - it would appear you want the container to be somehow available to any code within a given assembly set. Can you share it via a static? Or am I misunderstanding?
Oleg
Dec 3, 2008 at 9:12 PM
This is the same issue as if you are using Unity and want to access the unity container instance direct. Normally you would let not need to but sometimes you want to do something of your own with the actual container.

I have a sample of what I mean below which is a bit lengthy (sorry)!

The real question to me becomes what design situations would require you to reach for the MEF container it self and how can we avoid those? Normally we want inversion of control and recieve our instances - that have already been passed through any MEF importing!

Example with Unity to explain the situation:

If you do straight up vanilla build ups with for instance a webb application you are usually fine. Sometimes I see people try to connect some legacy messy code into their webb app before they have had time to rewrite it. The example I saw was that the legacy code had to be created with some parameters that were not known until run-time and so the case was that they wanted to grab hold of the unity container instance and set a new policy on it before going on with the build. Reason for doing this round about thing is to be able to set policies at run time based on parameters you have at the time and building up instances while being able to keep the legacy code away from being compile time referenced.

M.

On Tue, Dec 2, 2008 at 21:21, olegl <notifications@codeplex.com> wrote:

From: olegl

Trent, what are you trying to achieve here? We generally discourage the part authors to access the container even via importing, and it restricts their reuse. Sounds like that's not what you want either - it would appear you want the container to be somehow available to any code within a given assembly set. Can you share it via a static? Or am I misunderstanding?
Oleg

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/