ASP.NET MVC3 Внедрение зависимостей недоразумение - PullRequest
Новая
       11

ASP.NET MVC3 Внедрение зависимостей недоразумение

1 голос
/ 05 мая 2011 
public object GetService(Type serviceType)
{
    object resolvedObject = null;
    try
    {
        resolvedObject = _unityContainer.Resolve(serviceType);
    }
    catch(ResolutionFailedException e) { }

    return resolvedObject;
}

Является ли это лучшей практикой для перехвата исключения и возврата нуля?По умолчанию mvc пытается разрешить IControllerFactory и IViewPageActivator, т.е. я получаю два отслеживаемых исключения.Я не предпочитаю это решение.

Мой друг предлагает проверить serviceType на IControllerFactory, IViewPageActivator и, если возникнет исключение - поймать и зафиксировать ошибкуно что касается меня - это не лучшее решение, это как своего рода жесткий код.

Ответы [ 3 ]

5 голосов
/ 05 мая 2011

MVC3 DependencyResolver - это прежде всего сервисный локатор.По сути, это любовник MVC и Common Service Locator ( commonservicelocator.codeplex.com ).Различия между локатором сервисов CSL и MVC3 DependencyResolver заключаются в том, что архитекторы MVC решили, что им нужен более безопасный способ обработки случаев, когда сервисы не могут быть разрешены через него, и ответ, который они выбрали, заключался в том, что реализация IDependencyResolver должна вернутьнуль в этих обстоятельствах.

В CSL-реализациях IServiceLocator стандартной практикой является выброс ActivationException, который допускает стандартизированное исключение для обработки этих случаев.

При использовании MVC платформа будет вызывать DependencyResolverпопытаться решить настроенный сервис.Если он не может найти подходящий сервис, он использует значение по умолчанию.

Например, когда он хочет найти IControllerFactory, он сначала проверит DependencyResolver.Если там произойдет сбой, он будет использовать DefaultControllerFactory, настроенный через ControllerBuilder.SetControllerFactory(...).Благодаря такому подходу проверки в первую очередь лучше вернуть значение null, а затем разрешить всплывающее исключение для конкретного контейнера.

Это означает, что на этом этапе вы должны перехватить / проглотить любое исключение, поскольку платформа MVC не несет ответственности засправиться с этим за вас (бремя должно быть на самом контейнере / IDependencyResolver).

Вы можете записать это на этом этапе, но практика с MVC3 - возвращать ноль в этих случаях.

0 голосов
/ 03 апреля 2012

Для IControllerFactory вы можете 

.RegisterType<IControllerFactory, DefaultControllerFactory>()

Я не уверен, какие классы реализуют IViewPageActivator и ModelMetadataProvider.Событие, хотя исключение можно проглотить, исключая исключения, не является хорошей практикой просто потому, что в целом исключения влияют на производительность.Как только исключение вызвано, фреймворк заполняет трассировку стека, что требует времени.

0 голосов
/ 05 мая 2011

Это, очевидно, не лучшая практика, но ASP.NET MVC реализован таким образом, что, когда IoC не может разрешить службу, он должен возвращать ноль, чтобы инфраструктура mvc могла откатиться до значения по умолчанию. Пожалуйста, обратите внимание, что существует ряд сервисов, отличных от того, от чего зависит фабрика контроллеров / представлений, поэтому создание исключений нарушит их функционирование.

Я поспорил с дизайнерским решением во внутреннем списке рассылки asp.net, но так оно и есть: - (.

...