При организации проекта, где я должен помещать интерфейсы провайдера, которые используются в MEF? В настоящее время я просто имею их в том же проекте, что и все остальное, но мне кажется, что мне хотелось бы извлечь их в отдельную DLL, чтобы она была очень маленькой dll и с ней легко могли бы быть связаны другие, пытающиеся писать расширения. Что такое хорошая практика для этого?Где я должен поместить интерфейсы для MEF?
Как и в любой модели с подключаемым модулем/расширением, вы должны поместить свои «контракты» (интерфейсы, которые должен внедрять автор плагина) в сборке отдельно от вашего приложения.
Таким образом, вы можете сделать эту сборку доступной для авторов плагинов без необходимости передавать их всему приложению - полезно, если это коммерческое приложение, которое вам нужно лицензировать отдельно.
MEF Preview 5 представляет возможность экспорта интерфейса (т. Е. Добавить атрибут [Export] к интерфейсу), чтобы любой разработчик этого интерфейса автоматически экспортировался. Это означает, что авторам плагинов даже не нужно знать о MEF - они просто реализуют ваш интерфейс, и они автоматически являются расширением MEF.
Первоначально MEF собирался внедрить утиную печать, что означало бы, что вам не нужна общая сборка, но, видимо, это оказалось слишком сложным.
Я помещаю их в общую сборку вместе с полезными абстрактными базовыми классами, которые могут использоваться для реализации интерфейсов.
Интересно. Я сам пришел к одному и тому же образцу.Только мой интерфейс не является интерфейсом, это абстрактный класс, потому что в итоге я получил универсальную конечную функцию как настоящий код. – JCCyC
У меня также был такой же вопрос, и мне хотелось увидеть пример, где Контракты определены в одном проекте, несколько реализаций определены в других проектах и отдельные проекты потребителей, которые используют контракт и имеют папку расширения, где реализация dll's может быть просто скопирована и доступно для потребительского приложения без каких-либо изменений кода. Поэтому я попробовал написать простое приложение Hello World и опубликовал его в своем блоге. Надеюсь, вам это станет полезно. Я также разместил исходный код (в C#).
http://ppsinfo.blogspot.com/2009/11/managed-extensibility-framework-mef.html
На самом деле есть новая функция в .NET 4.0 называется тип эквивалентности, который может сделать это. С помощью этой функции вы можете создавать два разных интерфейса в разных сборках контрактов, которые сообщают CLR, что они одинаковы. Поскольку он является низкоуровневым, MEF может работать с ним хорошо.
Несколько предостережений:
Вы можете прочитать об этом здесь:.. http://msdn.microsoft.com/en-us/library/dd997297(VS.100).aspx документация будет сказать, что это для COM, но вы можете использовать его для управляемого кода, а
Экспорт интерфейса работает хорошо, если вы только когда-либо импортируете один из этих типов. Проблема в том, что если вы хотите использовать два из этого типа в разных частях приложения, то вам все равно потребуется имя контракта, так что вам понадобится экспорт , а? –
Да, если вам нужно импортировать две разные реализации одного и того же интерфейса, вам нужно каким-то образом их дифференцировать. Требование атрибута «Экспорт» на реализация - простой способ сделать это. Возможно, вы также можете использовать метаданные экспорта, но я вообще не играл с этим. –