Подтвердить что ты не робот

Реализация MEF с помощью ASP.NET MVC?

Я пытаюсь выяснить, есть ли у кого-нибудь опыт или идеи использования MEF (Managed Extensible Framework (Microsoft new plugin framework) с ASP.NET MVC. Мне нужно создать стандартный ASP.NET MVC, который у меня есть. Но мне нужно предложить дополнительную функциональность, т.е. Views и Controllers, и т.д., В зависимости от того, добавляю ли я плагин. Его не нужно динамически компилировать, т.е. исходный код... но DLL, которую я вставлял в систему.

Есть ли способ динамически загружать DLL, когда приложение запускается, а затем MERGE VIEWS и CONTROLLERS с основной системой? Я не знаю, нахожусь ли я на правильном пути здесь.

Затем, я полагаю, в представлениях "СТАНДАРТ", которые поставляются с приложением, я могу использовать "ЕСЛИ ЕСЛИ", чтобы узнать, загружен ли плагин и MERGE в пользовательском элементе управления.

Ну, я говорю здесь громко, но я думаю, вы понимаете, что я получаю.

Любые идеи?

4b9b3361

ОТВЕТЫ

Ответ 1

удачи с этим? Я читал этот и думаю, что вы ищете.
У меня ровно нуль xp с MEF, но он выглядит многообещающим. Надеюсь, я смогу скрестить несколько часов свободного времени вместе, чтобы поэкспериментировать с этим. Было бы очень полезно создать какую-то модульную структуру MVC.

Что касается текущего проекта, над которым я работаю, у меня возникает следующая проблема: Несколько сайтов с одинаковыми представлениями, только другие файлы CSS. В настоящее время мне приходится дублировать мнения, связанные с проблемой поддержки.
Я надеюсь, что смогу поместить эти взгляды в центральное место с помощью MEF.

Ответ 2

Проверьте это:

http://www.fidelitydesign.net/?p=104

Модульный ASP.NET MVC с использованием Managed Extensibility Framework (MEF), часть первая, Мэтью Эбботт.

Ответ 3

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

Однако мы также используем более гибкий подход к нашим контроллерам. Представления более сложны, но мы фактически полностью исключили использование обычных представлений ASP.NET MVC и сохранили наши представления Razor в фрагментах в базе данных. Затем наши контроллеры запрашивают механизм шаблонов для представления во время выполнения и выводят ContentResult в ответ вместо возврата View ( "Viewname" ) и т.д.

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

Итак, у вас может быть что-то вроде IUserController, который включает в себя методы для "Логин", "Выход из системы" и т.д.

В дополнение к этой фактической функциональности мы добавили бы GUID-свойство только для чтения в интерфейс под названием "SiteId". Каждая реализация затем жестко кодирует SiteId, для которого он предназначен. Для реализации по умолчанию в базовом коде он возвращает "Guid.Empty".

Затем, когда мы вызываем MEF и ищем какую реализацию IUserController для использования, мы будем делать ImportMany из всех из них в список, а затем использовать LINQ для запроса свойств, чтобы выяснить, какой из них использовать:

var _currentUserController = _availableUserControllers.FirstOrDefault(
  c=>c.SiteId == AppSettings.SiteId);
if(_currentUserController == null){
    //There is no site-specific override
    _currentUserController = _availableUserControllers.FirstOrDefault(
      c=>c.SiteId == Guid.Empty);
}

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

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

Ответ 4

Это дикое предположение. Вы можете перезаписать контроллер по умолчанию factory тем, который использует MEF для обнаружения IController s. Поскольку представления обнаружены по соглашению, вам не стоит беспокоиться о них.