Использование MEF на уровне сервиса (WCF) - PullRequest
Новая
       15

Использование MEF на уровне сервиса (WCF)

3 голосов
/ 07 июня 2011

До сих пор я обнаружил, что MEF хорошо работает с уровнем представления со следующими преимуществами.

а.DI (Dependency Injection)

b.Расширяемость третьей стороной (обратите внимание, что все вовлеченные стороны должны использовать MEF или использовать оболочки)

c.Автоматическое обнаружение деталей (расширений)

d.MEF позволяет помечать расширения дополнительными метаданными, что облегчает расширенные запросы и фильтрацию

e.Может использоваться для решения проблем управления версиями вместе с «динамическими ссылками DLR и c #» или «встраиванием типа»

Пожалуйста, исправьте меня, если я ошибаюсь.

Я занимаюсь исследованием того,использовать MEF на уровне сервиса с WCF.Пожалуйста, поделитесь своим опытом использования этих двух вместе и как MEF помогает вам?

Спасибо,

Нильс

Обновление

Вот мой результат исследований.Спасибо Мэтью за помощь в этом.

  1. MEF для основных услуг - стоимость изменений не оправдывает выгоды.Кроме того, это важное решение, которое может повлиять на уровень обслуживания в хорошем или плохом смысле, поэтому требует много изучения.MEF V2 (в ожидании стабильной версии) может быть лучше в этом случае, но мало беспокоится об использовании MEF V1 здесь.

  2. MEF для службы Function выполняет - MEF может добавить значение, но оно оченьспецифичные для сервисной функции.Чтобы принять это решение, нам нужно углубиться в необходимость обслуживания.

Обучение - это непрерывный процесс, поэтому, пожалуйста, поделитесь своими мыслями и опытом.

Ответы [ 3 ]

2 голосов
/ 08 июня 2011

Я думаю, что любая ситуация, которая выиграет от разделения проблем, выиграет от IoC. Проблема, с которой вы здесь сталкиваетесь, заключается в том, что вы требуете, чтобы MEF использовался в вашем сервисе. Будет ли это для самой основной службы или для какой-либо функции, которую выполняет служба.

Например, если вы хотите внедрить службы в ваши службы WCF, вы можете использовать что-то похожее на пример MEF для WCF в CodePlex. Я не слишком углубился в это, но, по сути, он оборачивает расположение службы через IInstanceProvider, позволяя вам настроить способ создания типа службы. Не уверен, поддерживает ли он инжектор конструктора (что было бы моим предпочтением), хотя ...?

Если компонент службы WCF находится не там, где вы хотите использовать MEF, вы все равно можете использовать преимущества MEF для создания подмножеств компонентов, используемых службой. Недавно для компании, в которой я работаю, мы перестраивали наш процесс предложения, и я построил гибкую модель расчета рабочего процесса, в которой единицами рабочего процесса являются составные части MEF, которые можно подключать при необходимости. Важной частью здесь будет управление тем, как ваш CompositionContainer используется в отношении времени жизни вашей службы WCF (например, поведение Singleton и т. Д.). Это очень важно, если вы решили каждый раз создавать новый контейнер (создание контейнера довольно дешево, тогда как создание каталога может быть дорогим).

Надеюсь, это поможет.

1 голос
/ 14 июля 2011

Я работаю над решением, в котором части MEF, которые я хочу использовать при вызовах WCF, хранятся в единственном экземпляре на уровне приложения.Все это размещено в IIS.Услуги оформлены для совместимости с asp.net.

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

В Global.asax я импортирую детали.

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

После инициализации каталога и контейнера я копирую импортированные объекты в мой одноэлементный класс. 

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

РЕДАКТИРОВАТЬ:

Мой класс реестра: 

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;
    }
}

Это работает, но я хочу сделать его потокобезопасным, поэтому я опубликую эту версию, как только она будет готова.

Потокобезопасный реестр: 

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;
    }

}
0 голосов
/ 17 ноября 2012

Некоторое время назад мне было интересно, как я могу создать веб-сервис WCF, который получит все его зависимости, связанные с MEF, но мне не нужно будет писать одну строку этого связанного кода внутри моего класса обслуживания.

Я также хотел, чтобы он полностью основывался на конфигурации, чтобы я мог просто перенести свое общее решение в следующий проект без необходимости вносить изменения в код.

Еще одно требование, которое я имел, состояло в том, что я должен быть в состоянии объединить- протестируйте сервис и легко смоделируйте его различные зависимости.

Я нашел решение, о котором я писал здесь: Unit-тестирование, WCF и MEF

Надеюсь, поможет людям, пытающимся сделать то же самое.

...