Using MEF in Service layer (WCF)

So far I found that MEF is going well with presentation layer with following benefits.

a. DI (Dependency Injection)

b. Third party extensibility (Note that all parties involved should use MEF or need wrappers)

c. Auto discovery of Parts (Extensions)

d. MEF allows tagging extensions with additional metadata which facilitates rich querying and filtering

e. Can be used to resolve Versioning issues together with “DLR and c# dynamic references” or “type embedding”

Pls correct me if I’m wrong.

I'm doing the research on whether to use MEF in Service layer with WCF. Pls share your experience using these two toge开发者_开发知识库ther and how MEF is helping you?

Thanks,

Nils

Update

Here is what my result of research so far. Thanks to Matthew for helping in it.

1. MEF for the Core Services - cost of changes are not justifying the benefits. Also this is big decision and may affect the service layer in good or bad way so needs lot of study. MEF V2 (Waiting for stable version) might be better in this case but little worried about using MEF V1 here.

2. MEF for the Function service performs - MEF might add the value but it’s very specific to the service function. We need to go deep into requirement of service to take that decision.

Study is ongoing process, so everyone please share your thoughts and experience.

I think any situation that would benefit from separation-of-concerns, would benefit from IoC. The problem you face here is how you require MEF to be used within your service. Would it be for the core service itself, or some function the service performs.

As an example, if you want to inject services into your WCF services, you could use something similar to the MEF for WCF example on CodePlex. I haven't looked too much into it, but essentially it wraps the service location via an IInstanceProvider, allowing you to customise how your service type is created. Not sure if it supports constructor injection (which would be my preference) though...?

If the WCF service component isn't where you want to use MEF, you can still take advantage of MEF for creating subsets of components used by the service. Recently for the company I work for, we've been rebuilding our Quotation process, and I've built a flexible workflow calculation model, whereby the workflow units are MEF composed parts which can be plugged in where needed. The important part here would be managing how your CompositionContainer is used in relation to the lifetime of your WCF service (e.g. Singleton behaviour, etc.). This is quite important if you decide to create a new container each time (container creation is quite cheap, whereas catalog creation can be expensive).

Hope that helps.

I'm working on a solution where the MEF parts that I want to use across WCF calls are stored in a singleton at the application level. This is all hosted in IIS. The services are decorated to be compatible with asp.net.

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

In Global.asax, I import the parts.

[ImportMany(typeof(IOption))]
public IEnumerable<IOption> AvailableOptions{ get; set; }

After initializing the catalog and container, I copy the imported objects to my singleton class.

container.ComposeParts(this);
foreach (var option in AvailableOptions)
    OptionRegistry.AddOption(option);

EDIT:

My registry class:

public static class OptionRegistry
{
    private static List<IOption> _availableOptions= new List<IOption>();

    public static void AddOption(IOption option)
    {
        if(!_availableOptions.Contains(option))
            _availableOptions.Add(option);
    }

    public static List<IOption> GetOptions()
    {
        return _availableOptions;
    }
}

This works but I want to make it thread safe so I'll post that version once it's done.

Thread-safe Registry:

public sealed class OptionRegistry
{

    private List<IOptionDescription> _availableOptions;
    static readonly OptionRegistry _instance = new OptionRegistry();

    public static OptionRegistry Instance
    {
        get { return _instance; }
    }


    private OptionRegistry()
    {
        _availableOptions = new List<IOptionDescription>();
    }


    public void AddOption(IOptionDescription option)
    {
        lock(_availableOptions)
        {
            if(!_availableOptions.Contains(option))
                _availableOptions.Add(option);
        }
    }

    public List<IOptionDescription> GetOptions()
    {
        return _availableOptions;
    }

}

A little while ago i was wondering how I could create a WCF web service that will get all of its dependencies wired by MEF but that i wouldnt need to write a single line of that wire up code inside my service class.

I also wanted it to be completely configuration based so i could just take my generic solution to the next project without having to make code changes.

Another requirement i had was that i should be able to unit-test the service and mock out its different dependencies in an easy way.

I came up with a solution that ive blogged about here: Unit Testing, WCF and MEF

Hopefully will help people trying to do the same thing.