Использование ServiceLocator в классах LIbraries и MVC DependencyResolver - PullRequest
Новая
       41

Использование ServiceLocator в классах LIbraries и MVC DependencyResolver

1 голос
/ 25 февраля 2011

Я действительно разбираюсь в DI / IoC - это делает некоторые вещи намного проще. Однако у меня есть несколько унаследованных классов, которые реализуют класс с необходимым конструктором без параметров, поэтому я использую сервисный локатор, чтобы получить то, что я хочу: 

MyMembershipProivder() : MyMembershipProvider(ServiceLocator.Current.GetInstance<...>){}
MyMembershipProivder(IMemberRepo memberRepo){...}

Работает отлично. Тем не менее, так как я также использую MVC3 DependencyResolver, у меня нет другого выхода, кроме как: 

var locator = new NinjectServiceLocator(kernel);
DependencyResolver.SetResolver(locator);
ServiceLocator.SetLocatorProvider(() => locator);

DependencyResolver используется в приложении MVC, а ServiceLocator используется в различных библиотеках классов.

Это идеальный способ сделать это? Я что-то упустил?

Обновление

В приведенном выше примере класс является специализированным провайдером предложения asp.net. Фабрика провайдеров членства asp.net требует, чтобы у моего пользовательского провайдера был конструктор без параметров, что вынуждает меня использовать локатор служб для внедрения репозитория, который он использует внутри.

Ответы [ 2 ]

2 голосов
/ 26 февраля 2011

Вам не нужен конструктор без параметров, средство разрешения зависимостей внедрит вашу зависимость в конструктор: 

MyMembershipProivder(IMemberRepo memberRepo){...}

Вы можете заменить фабрику контроллера по умолчанию (чтобы использовать конструкторы без параметров в ваших контроллерах): 

ControllerBuilder.Current.SetControllerFactory(new NinjectControllerFactory());

Вам не нужно заменять фабрику контроллера по умолчанию, см. Комментарий Linkgoron ниже.

В любом случае, я думаю, что использование Deoldency Resolver для вашего MVC-приложения и Service Locator для ваших библиотек классов - это нормально.

Надеюсь, это поможет.

0 голосов
/ 27 февраля 2011

Похоже, что у вас нет выбора, если вы не можете реорганизовать ваше приложение для использования DI с самого начала.Итак, я думаю, лучше использовать custom Service Service Locator.

Хотя, если унаследованные вами классы являются классами контроллеров, вы можете просто удалить конструкторы по умолчанию и покончить с этим, как MVCбудет обрабатывать все для вас.

Я никогда не видел класс ServiceLocator, это?

РЕДАКТИРОВАТЬ:

Как я уже сказалЯ не вижу, что у вас есть какой-либо другой вариант для развязки.Расположение службы, вероятно, является лучшим выбором, не привнося слишком большого объема и сложности.

Вещи, которые реализованы как нечто встроенное в .Net FW, вам следует искать конкретные решения, подобные представленным для поставщика членства.

...