NInject и MVC 3 - я должен использовать DependencyResolver вместо атрибута [Inject]? - PullRequest
Новая
       33

NInject и MVC 3 - я должен использовать DependencyResolver вместо атрибута [Inject]?

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

Недавно я перешел на MVC 3 и Ninject 2. В большей части кода я использую инъекцию конструктора, но есть некоторые места, где мне пришлось использовать атрибут Inject.Ninject 2 регистрирует свой собственный интерфейс IDepencyResolver.Мне не нравится, когда класс DependencyResolver является частью пространства имен System.Web.Mvc, потому что его функция не очень строго связана с MVC, но теперь, когда он там есть, я могу сделать 

public SomeClass 
{
    public IUserService UserService { get; set; }

    public SomeClass()
    {
        UserService = DependencyResolver.Current.GetService<IUserService>();

вместо

public SomeClass 
{
    [Inject]
    public IUserService UserService { get; set; }

, поэтому мне не нужно ссылаться на пространство имен Ninject в моих классах.Должен ли DependencyResolver использоваться таким образом?

Ответы [ 3 ]

5 голосов
/ 16 февраля 2011

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

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

Поэтому, чтобы ответить на ваш вопрос о внедрении свойства, я бы просто сказал: 

public SomeClass 
{
    public IUserService UserService { get; set; }

    public void SomeMethodWhichDoesntEnforceUserService()
    {
        if (UserService != null)
        {
            // Provide some additional functionality
        }
    }
}

и есливаш класс не может функционировать должным образом без пользовательского сервиса: 

public SomeClass 
{
    private readonly IUserService _userService;
    public SomeClass(IUserService userService)
    {
        _userService = userService;
    }

    public void SomeMethodWhichRequiresTheService()
    {
        _userService.DoSomething();
    }
}

Так что в обоих случаях нет ссылок на какие-либо особенности DI.Вот что такое Inversion of Control.

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

Первый вопрос, который я хотел бы задать, - почему вы не можете выполнить инжекцию конструктора IUserService в SomeClass? Это может указывать на проблему с дизайном.

Чтобы избежать прямой ссылки на DependencyResolver, вы могли бы реализовать некоторую форму абстракции локатора служб поверх структуры DI, например, CommonServiceLocator , но, как ответ на этот вопрос , такие абстракции не должны быть необходимыми для правильного выполнения DI. Вместо этого вы должны настроить дизайн приложения.

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

Я считаю, что версия ninject.web.mvc для mvc3 теперь поддерживает внедрение конструктора в атрибуты фильтра.Вы пробовали это?

...