Какова лучшая альтернатива модели провайдера ASP.NET, если также используется IOC? - PullRequest
0 голосов
/ 13 декабря 2011

Модель провайдера ASP.NET была отличной технологией для решения проблемы, позволяющей кому-то «подключить» отдельную реализацию некоторых функций в веб-приложение. Модель провайдера, как правило, немного болезненна для реализации, требуя настройки, поэтому она используется минимально.

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

Если веб-приложение использует контейнер IOC, кажется неправильным также использовать модель провайдера, потому что вы, кажется, абстрагируете что-то, что уже абстрагировано, создавая два уровня сложности (за исключением, возможно, для существующих провайдеров - I Я говорю о создании пользовательских провайдеров).

(подробнее об этом в моем блоге: http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html)

Я использую AutoFac для IOC, и возможно разрешить «переопределение конфигурации», так что это кажется хорошей альтернативой для того же решения, которое дает мне модель провайдера, однако я не очень много знаю о том, как мог бы соответствовать MEF это требование или если есть что-то еще, что я пропускаю?

Если вы могли разработать веб-приложение ASP.NET MVC с нуля, и требовалось, чтобы вам приходилось продавать упакованную версию, чтобы другие могли "подключить" определенные фрагменты доступа к данным без необходимости повторной компиляции Как бы вы это реализовали?

Ответы [ 2 ]

1 голос
/ 13 декабря 2011

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

Некоторые вещи должны быть провайдерами. Например, если вы используете функции от стандартного поставщика членства ASP.NET, вы должны извлечь свою функциональность из этого. В этих ситуациях я обнаружил, что достаточно просто написать своего рода «прокси-провайдер», который выполняет разрешение зависимостей и передает вызов реализации, зарегистрированной в DI.

Например, если у вас есть Autofac, подключенный к MVC DependencyResolver, вы можете увидеть что-то вроде этого в вашем членском провайдере:

public override bool ChangePassword(
  string username,
  string oldPassword,
  string newPassword)
{
  var provider = DependencyResolver.Current.GetService<IMembershipService>();
  return provider.ChangePassword(username, oldPassword, newPassword);
}

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

Для вещей, которые не являются поставщиками, просто используйте функциональность IoC как обычно. Я предпочитаю IoC без конфигурации, использующий функции сканирования сборок Autofac и , которые позволят вам в основном поместить сборку с переопределениями в папку bin и перезапустить приложение. Сканирование любых модулей при запуске и регистрация их. Если вы хотите быть более явным, вы можете создать свой собственный интерфейс запуска, например ...

public interface IMyStartup
{
  void Start(ContainerBuilder builder);
}

... а затем отсканируйте только ваш конкретный интерфейс и вызовите метод start для этого. Существует множество способов сделать это (атрибуты, типы, сборки в определенном известном месте и т. Д.), Но все сводится к сканированию сборки.

0 голосов
/ 13 февраля 2013

Карта Unity и структуры также. Обеспечить сканирование сборки.Для этого Unity требуется модуль автоматической регистрации.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...