Новый проект Prism-использовать MEF или Unity?
Я начинаю новый проект personal Prism 4. В эталонной реализации в настоящее время используется Unity.
Я хотел бы знать, должен ли я использовать MEF вместо этого или просто придерживаться Unity.
Я знаю, что несколько дискуссий упомянули, что эти два разных, и они пересекаются, но я пропущу, если я просто выберу единство на всем пути?
3 ответов
также проверить документация:
ключевое решение: выбор контейнера для инъекций зависимостей
библиотека Prism предоставляет два варианта для зависимостей контейнеров впрыски : Единство или MEF. Призма раздвижная, тем самым позволяя другим контейнерам вместо немного работа. Оба Unity и MEF обеспечивают же базовые функции инъекция зависимости, даже если они работают совсем по-другому.
некоторые из возможностей, предоставляемых обоими контейнерами, включают следующее:
- они оба регистрируют типы с контейнером.
- они оба регистрируют экземпляры с контейнером.
- они оба императивно создают экземпляры зарегистрированных типов.
- они оба вводят экземпляры зарегистрированных типов в конструкторы.
- они оба вводят экземпляры зарегистрированных типов в свойства.
- они оба имеют декларативные атрибуты для маркировки типов и зависимостей, которыми нужно управлять.
- они оба разрешают зависимости в графе объектов.
Unity предоставляет несколько возможности, которые MEF не делает:
- он разрешает конкретные типы без регистрации.
- он разрешает открытые дженерики.
- он использует Перехват для захвата вызовов объектов и добавления дополнительных функциональность целевого объекта.
MEF предоставляет несколько возможности такого единства нет:
- он обнаруживает сборки в каталоге.
- он использует загрузку файлов XAP и обнаружение сборки.
- восстанавливает свойства и коллекции по мере обнаружения новых типов.
- он автоматически экспортирует производные типы.
- он развертывается с .NET Framework.
в настоящее время я занимаюсь тем же расследованием. На прошлой неделе я был на симпозиуме p&p в Редмонде. У меня была возможность пообщаться с некоторыми людьми из p&p по этому поводу.
MEF
+ часть .net, нет необходимости в дополнительных библиотеках
+ очень мощный в расширяемости, модульности сценариев
- более общий подход, менее гибкий для сценариев DI
- вам нужно украсить атрибутами, ваш код приклеен к MEF
единство
+ очень гибкий для сценариев DI
+Если вы придерживаетесь инъекции ctor и избегаете использования именованных экземпляров, то вы не нужно использовать какие-либо атрибуты. Наиболее вашей системы не полагается на Unity
- нет из коробки поддержка расширяемости, сценариев модульности
- необходимо развернуть библиотеки 3rdparty
Что я думаю, это хорошо идея состоит в том, чтобы использовать MEF для расширяемости (управлять модулями вашего приложения, локализовать регистрации) и использовать Unity для DI.
Ну, это должно быть ясно, что MEF реализует инверсию управления, но она не является его частью, поэтому это означает, что они не одинаковы, есть разница, что мы используем unity, когда у нас есть статическая зависимость, а MEF предоставляет нам динамическую зависимость.
MEF также предоставляет нам расширяемость, с помощью которой мы можем вызвать механизм типа порта, а также определить тип компонента, который может взаимодействовать через этот порт. подробнее можно понять из: в MSDN Документ