Как явно и точно контролировать объем композиции? - PullRequest
Новая
       2

Как явно и точно контролировать объем композиции?

2 голосов
/ 16 декабря 2011

Меня интересуют способы контроля объема композиции с помощью MEF.

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

Я смотрю предварительный просмотр MEF2 и пытаюсь понять его, но почему-то не вижу полного решения.

С одной стороны, есть этот модуль интеграции MVC , где MEF достаточно хорош, чтобы позаботиться о объеме запроса для меня, но это не очень удобно вне MVC (и вне сети для этого имеет значение), это?

С другой стороны, в первом посте, связанном с предварительным просмотром " Что нового в MEF2 ", я видел вещь под названием CompositionScopeDefinition, которая выглядит как явная спецификация для областей, но с этим Во-первых, я не вижу способа «закрыть» прицел. Другими словами: как MEF определяет, когда утилизировать компоненты, созданные в области действия?

И с другой стороны (да :-), с MEF v1, я имел обыкновение иметь дело с областью видимости, создавая вложенные CompositionContainer s, но это не очень хорошо работает с пользовательскими ExportProvider s.

Что бы действительно хотелось увидеть, это что-то вроде: 

   using( var scope = compositionContainer.OpenScope( /* some scope definition here */ ) )
   {
      var rootComponent = scope.GetExport<MyRootComponent>(); // The component graph gets composed at this point
      rootComponent.DoYourScopedThing();
   } // The component graph gets disposed at this point

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

Итак, еще раз вопрос: что вы используете для решения подобных задач? Или вы говорите, что MEF еще недостаточно зрел для серьезного использования?

Ответы [ 2 ]

3 голосов
/ 17 декабря 2011

Хороший вопрос - мы работаем над дополнительной документацией, которая должна ответить на ваш вопрос о CompositionScopeDefinition.Укороченная версия;CSD используется через ExportFactory<T>, где CreateExport() возвращает дескриптор, который используется для управления временем жизни области действия.

Однако CSD предназначен и оптимизирован для сценариев настольных приложений;как вы, несомненно, видели, интеграция MVC использует отфильтрованные каталоги и вложенные контейнеры для управления временем жизни.Это все еще рекомендуемый подход для «транзакционного» времени жизни в сети и других сценариях обработки работ.

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

Более сильная «обычная» жизненная история - это то, над чем мы очень много работаем;Дайте нам знать о том, где MEF 2 не подходит для ваших сценариев, особенно через дискуссионный форум CodePlex, - это большая помощь.

0 голосов
/ 29 февраля 2012

Я нашел этот пост в поисках подробностей о CSD.Я хочу использовать MEF для создания расширяемого приложения WPF, которое имеет экранную навигацию, которая позволяет клиенту открывать экран за экраном внутри одного окна.Каждый экран должен иметь доступ к настройкам деталей на предыдущих экранах, а также иметь возможность отменять некоторые детали.Например, когда пользователь открывает ProcessView, он должен иметь часть ProcessProvider, которая может быть импортирована с помощью экрана, перемещаемого из ProcessView, скажем, ActivityView.ActivityView должен иметь доступ к ProcessProvider, чтобы у него был контекст для работы.

Другой пример - это то, что на корневом экране может быть ProcessListProvider, который по умолчанию возвращает все процессы в базе данных.Экран, который хочет открыть ProcessListView, должен каким-то образом переопределить корневой ProcessListProvider с настроенным ProcessListProvider, чтобы ProcessListView продолжал работать, но с настроенным поставщиком списка процессов.

Я надеюсь, что смог сообщить свои требования.

Идо.

...