Соображения при разработке расширяемого приложения с использованием MEF - PullRequest
Новая
       23

Соображения при разработке расширяемого приложения с использованием MEF

2 голосов
/ 13 марта 2010

Я начал экспериментировать с внедрением зависимостей (в частности, MEF) для одного из моих проектов, у которого есть несколько различных точек расширяемости. Я начинаю чувствовать, что я могу сделать с MEF, но я хотел бы услышать от других, которые имеют больше опыта с технологией. Несколько конкретных случаев:

  1. Мой основной сценарий использования на данный момент - раскрытие различных синглтоноподобных сервисов, которыми пользуются мои расширения. Моя сборка Framework предоставляет сервисные интерфейсы, а сборка Engine содержит конкретные реализации. Это хорошо работает, но я не хочу, чтобы все мои расширения имели доступ ко всем моим службам. Есть ли хороший способ в MEF ограничить, какой конкретный импорт я разрешаю разрешать только что созданному расширению?

  2. Это конкретное приложение имеет объекты расширения, которые я неоднократно создаю. Я могу импортировать несколько типов контроллеров и машин, которые создаются в различных комбинациях для проекта. Я не смог найти хороший способ сделать это с помощью MEF, поэтому я делаю свое собственное обнаружение и создание экземпляров. Есть ли хороший способ сделать это в MEF или других структурах DI?

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

1 Ответ

1 голос
/ 14 марта 2010

Есть ли хороший способ в MEF ограничить какой конкретный импорт я разрешаю недавно созданное расширение к решить? * * 1002

Загрузите код расширения в отдельный контейнер и убедитесь, что запрещенные части недоступны в этом контейнере. Давайте упростим ситуацию с этими классами, чтобы построить пример: 

[Export]
public class MyExtension
{
   [Import]
   public PublicService Service { get; set; }

}

[Export]
public class PublicService
{
}

[Export]
public class InternalService
{
}

[Export]
public class Program
{
   [Import]
   public MyExtension Extension { get; set; }

   [Import]
   public PublicService Service1 { get; set; }

   [Import]
   public InternalService Service2 { get; set; }
}

Цель состоит в том, чтобы разрешить MyExtension импортировать PublicService, но не InternalService. Внутренний код типа Program должен иметь возможность импортировать что угодно. Вы можете достичь этого следующим образом: 

var publicCatalog = new TypeCatalog(typeof(PublicService), typeof(MyExtension));
var publicContainer = new CompositionContainer(publicCatalog);

var internalCatalog = new TypeCatalog(typeof(Program), typeof(InternalService));
var internalContainer = 
    new CompositionContainer(internalCatalog, publicContainer);

var program = internalContainer.GetExport<Program>();

Этот код не будет генерировать исключение композиции. Если вы теперь измените импорт на MyExtension на запрещенный InternalService, вы получите требуемое исключение для композиции.

Побочным эффектом этой настройки является то, что PublicService также не может импортировать частные сервисы, как и MyExtension. Этот вид имеет смысл, потому что иначе ничто не помешает PublicService раскрыть частную службу через свойство.

Я использовал TypeCatalog для примера, но на практике вам, вероятно, следует использовать что-то вроде FilteredCatalog sample .

Это конкретное приложение имеет объекты расширения, которые я неоднократно экземпляр. Я могу импортировать несколько типы контроллеров и машин, которые создаются в разных комбинации для проекта. Я не мог найти хороший способ сделать это с MEF, так что я делаю свое собственное открытие типа и конкретизации. Есть ли хороший способ сделать это в MEF или другом DI рамки?

Возможно, вы находитесь только после атрибута PartCreationPolicy, который определяет, является ли деталь общей (например, созданной только один раз для контейнера) или созданной несколько раз для каждого импорта. Вы также можете указать параметр RequiredCreationPolicy в атрибуте импорта.

Если это не решит вашу проблему, взгляните на образец PartCreator в источниках MEF (хотя обратите внимание, что он, вероятно, скоро будет переименован в ExportFactory, он уже был в редакции silverlight MEF).

...