Рассматривая Microsoft Managed Extensibility Framework (MEF) и различные контейнеры IoC (например, Unity), я не вижу, когда использовать один тип решения по другому. Более конкретно, похоже, что MEF обрабатывает большинство шаблонов типа IoC и что контейнер IoC, такой как Unity, не будет таким необходимым.
В идеале я хотел бы видеть хороший вариант использования, когда вместо IOC или в дополнение к MEF будет использоваться контейнер IoC.
При сваривании основное отличие заключается в том, что контейнеры IoC обычно наиболее полезны для статических зависимостей (известных во время компиляции), а MEF обычно наиболее полезен с динамическими зависимостями (известными только во время выполнения).
Как таковые, они оба являются двигателями состава, но акцент очень различен для каждого шаблона. Таким образом, решения по дизайну сильно варьируются, поскольку MEF оптимизирован вокруг обнаружения неизвестных частей, а не регистрации известных частей.
Подумайте об этом так: если вы разрабатываете все свое приложение, лучше всего использовать контейнер IoC. Если вы пишете о расширении, так что сторонние разработчики будут расширять вашу систему, MEF, вероятно, лучше всего.
Кроме того, статья в ответе @Pavel Nikolov дает некоторое большое направление (она написана Glenn Block, менеджером программ MEF).
Я использую MEF некоторое время, и ключевым фактором, когда мы используем его вместо продуктов IOC, является то, что мы регулярно имеем 3-5 реализаций данного интерфейса, которые находятся в нашем каталоге плагинов в данный момент времени. Какую из этих реализаций следует использовать, это то, что можно решить только во время выполнения.
MEF умеет позволять вам делать именно это. Как правило, IOC ориентирован на то, чтобы вы могли поменять местами, для кононического примера, IUserRepository на основе продукта ORM 1 для продукта ORM 2 в какой-то момент в будущем. Однако большинство решений МОК предполагают, что в данный момент будет действовать только один IUserRepository.
Если, однако, вам нужно выбрать один на основе входных данных для заданного запроса страницы, контейнеры IOC обычно теряются.
В качестве примера мы проводим проверку наших прав и нашу проверку через плагины MEF для большого веб-приложения, над которым я работал некоторое время. Используя MEF, мы можем посмотреть, когда записана дата CreateOn и перейти на плагин проверки, который фактически действовал, когда была создана запись, и запустить запись BOTH через этот плагин И валидатор, который в настоящее время действует, и сравнить срок действия записи над время.
Этот тип мощности также позволяет нам определять переполнения паттерна для плагинов. Приложения, над которыми я работаю, на самом деле являются той же базой кода, которая была развернута для 30+ реализаций. Итак, мы обычно ищем плагины, прося:
Это позволяет нам объединить набор плагинов по умолчанию, которые будут задействованы, но только если эта конкретная реализация не отменяет его с конкретными правилами клиента.
IOC - отличная технология, но, по-видимому, это скорее упрощает кодирование интерфейсов вместо конкретных реализаций. Тем не менее, замена этих реализаций является скорее видом события проекта в МОК. В MEF вы берете на себя гибкость интерфейсов и конкретных реализаций и делаете это временем выполнения многих доступных параметров.
Я извиняюсь за то, что не в тему. Я просто хотел сказать, что есть два недостатка, которые делают MEF ненужным осложнением:
это атрибут, который не помогает вам понять, почему все работает так, как они. Там нет способа добраться до деталей, надетых во внутренностях рамки, чтобы увидеть, что именно происходит там. Нет способа получить журнал трассировки или подключиться к разрешающим механизмам и вручную обрабатывать нерешенные ситуации.
у него нет механизма устранения неполадок, чтобы выяснить причины отказа некоторых частей. Несмотря на то, что он указывает на неисправную часть, он не говорит вам, почему эта часть потерпела неудачу.
Поэтому я очень разочарован этим. Я провел слишком много времени, сражаясь с ветряными мельницами, пытающимися запустить несколько классов вместо того, чтобы работать над реальными проблемами. Я убежден в том, что нет ничего лучше, чем метод инъекций старой школы, когда вы полностью контролируете то, что создано, когда и может отслеживать что-либо в отладчике VS. Хотелось бы, чтобы кто-то, кто защищал MEF, представил массу веских причин, почему я должен выбирать его по простому DI.
Я согласен, что MEF может быть полностью совместимой картой IoC. Фактически я пишу приложение прямо сейчас на основе использования MEF как для расширяемости, так и для IoC. Я взял общие части и превратил его в "рамки" и открыл его как свою собственную структуру под названием SoapBox Core в случае, если люди хотят чтобы увидеть, как это работает.
В частности, посмотрите, как работает Host, если вы хотите видеть MEF в действии.