Как вы используете среду управляемого расширения?

Я работаю с MEF около 2 недель. Я начал думать о том, для чего нужен MEF, изучил, как использовать MEF, и, наконец, реализовал хост с 3 модулями. Контракты оказываются легко понять, и модули легко управляются.

Хотя MEF имеет очень практическое применение, мне интересно, в какой степени? Я имею в виду, все ли будут переписывать существующие приложения для расширяемости?

Да, это звучит и безумно нецелесообразно. Риторически говоря:

• Как MEF влияет на современные тенденции в программировании?

• Вы начали искать возможности использовать MEF?

• Вы начали планировать серьезное переписывание существующего приложения, которое может выиграть от расширяемости?

Тем не менее, мои вопросы:
как мне узнать, когда я должен планировать новый проект с расширяемостью?
Как я узнаю, что существующий проект необходимо переписать для расширения?

Кто-нибудь использует MEF?

Кто-нибудь использует MEF?

Я работаю над проектом Silverlight, используя шаблон MVVM. Мы начали с простого подключения всех виртуальных машин по мере необходимости через интерфейсы и ручное внедрение зависимостей (конструктор или свойство в зависимости от необходимости). Это начало становиться болезненным, и мы начали использовать MEF в качестве основы для внедрения зависимостей, чтобы экспортировать определенные сервисы, которые используются в моделях представления, и импортировать их в модели представления, которые в них нуждаются. Работает отлично и с очень небольшим кодом.

Да, есть некоторые пуристы, которые скажут, что MEF не предназначен для внедрения зависимостей, и реальная структура внедрения зависимостей будет работать намного лучше. Однако MEF встроен прямо в .NET, что является большим плюсом, и этого было достаточно для удовлетворения наших потребностей.

как узнать, когда мне следует планировать новый проект с возможностью расширения? Как я узнаю, что существующий проект необходимо переписать для расширения?

ИМО, вы всегда должны соответствующим образом разделять проблемы и использовать интерфейсы, чтобы позволить различным модулям изменяться независимо. Если вы все сделаете правильно, тогда, когда вы обнаружите необходимость в расширяемости, MEF будет легко добавить. Но я бы не стал запускать проект, который не имел требований к расширяемости, и на всякий случай поставил бы MEF. Я бы подождал, пока возникнет необходимость. Для существующих проектов, если возникнет необходимость, я бы оценил усилия по перестройке проекта, чтобы использовать MEF в сравнении с альтернативными решениями, а не бездействовать, и посмотреть, какие из них выиграют.

Люди совершают ошибку, и я думаю, что это из-за именования (Managed Extensibility Framework) заключается в том, что MEF практичен только для расширяемости. MEF действительно учитывает три ключевых момента: расширяемость, обнаружение и метаданные. Последние два очень полезны даже для приложения, которое никогда не увидит ни одного плагина или расширения.

Это статья, которую я написал о ее способности обнаруживать как контейнер IOC: http://www.informit.com/articles/article.aspx?p=1635818

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

В настоящее время я использую MEF в нескольких проектах, которые включают шаблон Repository.

Один использует разные типы репозиториев во время модульного тестирования, другой проект использует локальные (прямо в БД), удаленные (WCF) и тестовые репозитории.

Оба проекта могут изменять свои типы репозитория с помощью кода или конфигурации и основаны на метаданных MEF / типах Lazy.

На сегодняшний день оба проекта работают невероятно хорошо.