Managed Extensibility Framework

Managed Extensibility Framework (MEF) — это библиотека классов для платформы .NET, предназначенная для создания расширяемых приложений. MEF реализует концепцию композитного приложения, позволяя разработчикам динамически обнаруживать и использовать модули (расширения) во время выполнения, без необходимости явной компиляции или настройки связей между компонентами. Библиотека входит в состав .NET Framework (начиная с версии 4.0) и .NET Core (начиная с версии 3.0), а также доступна как отдельный пакет NuGet для более старых версий.

История

MEF был разработан группой инженеров Microsoft, включая Гленна Блока (Glenn Block), который также известен своей работой над Windows Communication Foundation (WCF). Первая публичная версия MEF (CodePlex) была выпущена в 2008 году как предварительная сборка. Основной целью было упрощение разработки плагинных архитектур и уменьшение связности между компонентами приложения.

В 2010 году MEF был включён в состав .NET Framework 4.0 как часть пространства имён System.ComponentModel.Composition. В последующих версиях .NET Framework (4.5, 4.6, 4.7, 4.8) библиотека обновлялась, в основном, для исправления ошибок и повышения производительности.

С выходом .NET Core 3.0 (2019 год) MEF был переписан и адаптирован для работы на кроссплатформенной среде. Новая версия, получившая название System.Composition (или MEF 2), была оптимизирована для использования в современных приложениях, включая ASP.NET Core, и поддерживает асинхронную загрузку модулей.

Архитектура и принципы работы

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

Основные компоненты

1. Контракты (Contracts): Определяют интерфейс, который должен реализовать модуль. Контракт может быть представлен типом (интерфейсом, классом) или строкой.
2. Части (Parts): Классы, реализующие контракт. Части помечаются атрибутом [Export], указывающим, какой контракт они предоставляют.
3. Импорты (Imports): Точки, в которые MEF внедряет найденные части. Импорты помечаются атрибутом [Import]. Они могут быть одиночными (для одного модуля) или коллекциями (для всех модулей, реализующих контракт).
4. Каталоги (Catalogs): Источники, из которых MEF получает информацию о доступных частях. Стандартные каталоги включают:

• AssemblyCatalog — сканирует одну сборку.
• DirectoryCatalog — сканирует все сборки в указанной директории.
• AggregateCatalog — объединяет несколько каталогов.

1. Контейнер (CompositionContainer): Центральный объект, который управляет созданием, связыванием и жизненным циклом частей. Контейнер получает список каталогов и выполняет композицию.

Процесс композиции

1. Приложение создаёт экземпляр CompositionContainer, передавая ему один или несколько каталогов.
2. Контейнер сканирует сборки, находит все классы с атрибутом [Export] и регистрирует их.
3. При запросе импорта (например, при создании объекта с атрибутом [Import]) контейнер автоматически создаёт экземпляр соответствующей части и связывает его с импортом.
4. Если импорт является коллекцией ([ImportMany]), контейнер создаёт экземпляры всех частей, реализующих данный контракт.

Версии MEF

MEF 1 (System.ComponentModel.Composition)

• Входит в состав .NET Framework 4.0–4.8.
• Использует атрибуты из пространства имён System.ComponentModel.Composition.
• Поддерживает только синхронную загрузку.
• Более тяжёлый и менее гибкий по сравнению с MEF 2.
• Основной класс — CompositionContainer.

MEF 2 (System.Composition)

• Входит в состав .NET Core 3.0+ и .NET 5+.
• Использует атрибуты из пространства имён System.Composition.
• Поддерживает асинхронную загрузку (async/await).
• Более лёгкий и быстрый, оптимизирован для современных приложений.
• Основной класс — CompositionHost.
• Поддерживает сценарии с открытыми дженериками (Open Generics).

Применение

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

Типичные сценарии

1. Плагинные системы: Приложения, которые позволяют сторонним разработчикам создавать расширения. Примеры: текстовые редакторы, IDE (например, Visual Studio Code частично использует MEF), графические редакторы.
2. Модульные приложения: Крупные корпоративные системы, где функциональность разбита на независимые модули (например, CRM, ERP). MEF позволяет динамически загружать модули в зависимости от конфигурации или прав пользователя.
3. Серверные приложения: ASP.NET Core использует MEF 2 для управления зависимостями и загрузки middleware. Хотя встроенный DI-контейнер ASP.NET Core не является MEF, MEF может быть интегрирован для сложных сценариев расширения.
4. Тестирование: MEF упрощает создание модульных тестов, так как позволяет заменять реальные части на заглушки (mocks) через контракты.

Пример использования

```csharp // Определение контракта public interface IPlugin { string Name { get; } void Execute(); }

// Реализация плагина [Export(typeof(IPlugin))] public class HelloPlugin : IPlugin { public string Name => "Hello Plugin"; public void Execute() => Console.WriteLine("Hello from MEF!"); }

// Главное приложение public class Host { [ImportMany] public IEnumerable<IPlugin> Plugins { get; set; }

public void Run() { // Создание каталога и контейнера var catalog = new DirectoryCatalog("Plugins"); var container = new CompositionContainer(catalog); container.ComposeParts(this);

// Использование плагинов foreach (var plugin in Plugins) { plugin.Execute(); } } } ```

Критика и ограничения

1. Сложность отладки: Поскольку MEF создаёт объекты динамически, ошибки композиции (например, отсутствие части для импорта) могут быть трудно диагностируемы. Исключения часто содержат общие сообщения, не указывающие на конкретную проблему.
2. Производительность: Сканирование сборок и создание контейнера может быть медленным, особенно при большом количестве модулей. MEF 2 частично решает эту проблему за счёт асинхронной загрузки.
3. Избыточность для простых задач: Для небольших приложений или приложений с фиксированным набором модулей использование MEF может быть излишним. В таких случаях проще использовать стандартные фабрики или DI-контейнеры (например, Autofac, Unity).
4. Отсутствие строгой типизации: Атрибуты [Export] и [Import] не проверяются на этапе компиляции. Ошибка в имени контракта (если используется строка) проявится только во время выполнения.

Сравнение с другими технологиями

Интересные факты

• MEF изначально разрабатывался как часть проекта CodePlex, который был закрыт в 2017 году. Исходный код MEF 1 до сих пор доступен в архивах.
• В Visual Studio 2010 и более поздних версиях MEF используется для реализации расширений (Extensions). Разработчики могут создавать собственные плагины для редактора кода, системы сборки и других компонентов.
• MEF 2 был полностью переписан с нуля и не имеет обратной совместимости с MEF 1. Для перехода с MEF 1 на MEF 2 требуется изменение кода.
• В .NET 5 и .NET 6 MEF 2 был включён в состав пакета Microsoft.NET.Sdk.Web для ASP.NET Core, что упростило его использование в веб-приложениях.

Источники

1. Документация Microsoft по MEF 1 (System.ComponentModel.Composition).
2. Документация Microsoft по MEF 2 (System.Composition).
3. Книга «Pro .NET 4 Parallel Programming in C#» (глава о MEF), Adam Freeman, 2010.
4. Статья «Managed Extensibility Framework (MEF) vs. Dependency Injection» на MSDN Magazine, 2010.
5. Исходный код MEF 1 на GitHub (архив CodePlex).
6. Официальный блог команды .NET (объявления о выпуске MEF 2).