2012-03-12 3 views
0

Наследование от MVC контроллер классаNinject Конструктор инъекции и построить proble, с

public class BaseController : Controller 
{ 

    private ITenantRepository _repository; 
    [Inject] 
    public BaseController(ITenantRepository repository) 
    { 
     _repository = repository; 
    } 
    protected override void Initialize(System.Web.Routing.RequestContext requestContext) 
    { 
     base.Initialize(requestContext); 
    } 
} 

не может построить

BaseController»не содержит конструктор, который принимает аргументы 0

явно мне не хватает что-то очевидное.

+0

Ctrl-Alt-O, пойти посмотреть, где вы делаете 'новый BaseController()' и передать в макете/заглушкой. Но наиболее важно, посмотрите на один из 50 tuttorials там и сохраните hyourself проб и ошибок. (Или даже лучше, купите manning.com/seemann и камбалу вокруг еще меньше). Обратите внимание, что [Inject] не приводит к тому, что что-то происходит сам по себе (на самом деле это suprtfluous) - 'DependencyResolver' необходимо подключить к конвейеру ASP.NET MVC. См. Пакет NuGet Ninject.MVC3 и связанные с ним документы на странице https://github.com/ninject/ninject.web.mvc/wiki/MVC3 –

ответ

2

В своих дочерних контроллерах убедитесь, что вы определили конструктор с теми же параметрами, как базовый класс:

public class FooController: BaseController 
{ 
    public FooController(ITenantRepository repository): base(repository) 
    { 
    } 

    ... 
} 

Вы должны сделать это, потому что в базовом классе вы удалили конструктор без параметров и заменить это с обычным. Поэтому производные классы также должны быть удалены из их конструктора без параметров.

Также обратите внимание, что обычный способ использования Ninject с ASP.NET MVC - установить его как DependencyResolver на верхнем уровне вашего приложения. Контроллеры не должны использовать какие-либо специфичные для контейнера атрибуты, такие как атрибут [Inject], который вы использовали, поскольку они связывают ваш код с контейнером инъекции зависимостей, который вы используете.

Следует также отметить, что в дополнение к плохой практикой с предыдущей точки зрения, атрибут конструктора в коде [Inject] не имеет существенного влияния:

  • Ничто не собирается вмешаться и сказать: «Посмотрите, у него есть атрибут, мы лучше обеспечить его зависимости
  • Если бы Ninject настроен как DependencyResolver, он не будет нужен атрибут, поскольку нет никакой двусмысленности вообще относительно того, что нужно, чтобы построить контроллер
    • там нет default constr uctor
    • нет никакого конкурирующего конструктору
+0

[Как вы, очевидно, хорошо знаете] Атрибут Inject не имеет цели для ctor даже в Ninject, кроме как для устранения неоднозначности выбора конструктора. То, как вы выразились, говорит о том, что он может сделать что-то (вместо «DependencyResolver» –

+0

@RubenBartelink, это правда. Я обновил сообщение, чтобы это отразить. –

+0

Расширил мой комментарий и отредактировал то, d сказал, извините, если его сумасшедший давно наматывается. Надеюсь, что +1 компенсирует это! –

Смежные вопросы