MVC 3-зависимый резольвер или Ninject MVC-плагин?

Ответ 1

Расширение Ninject.Web.MVC(или NuGet Ninject.MVC3 NuGet) также использует внутреннее средство зависимостей. Таким образом, в основном он использует тот же механизм. Но есть несколько причин использовать расширение, а не реализовать собственный преобразователь зависимостей:

• Зачем внедрять собственный зависимый преобразователь, когда уже существует расширение, выполняющее точно то же самое? Использование той же самой реализации, что и другие, облегчает вам поддержку при возникновении проблемы. Более того, чем больше использует ту же реализацию, тем более стабильной она становится. (См. Пункт 4).
• Расширение больше, чем просто преобразователь зависимости. См. http://www.planetgeek.ch/2010/11/13/official-ninject-mvc-extension-gets-support-for-mvc3/ для списка всех функций, прилагаемых к расширению.
• Он добавляет поддержку быстрой дезактивации объектов InRequestScope после завершения запроса по умолчанию. Это предотвращает запуск приложений с большой нагрузкой в ​​исключение OutOfMemory.
• У вас есть проблема с преобразователем зависимостей в вашем сообщении и выше. В некоторых ситуациях при большой нагрузке ваше приложение будет разбиваться и отображать только желтые страницы смерти до тех пор, пока приложение не будет перезапущено. Мне не нравится отвечать на все вопросы, которые появятся в будущем только потому, что используется ошибочный преобразователь зависимостей. Добавьте, по крайней мере,.ToList() в GetServices
• Поддержка InRequestScope будет удалена в Ninject 2.4, чтобы удалить зависимость от System.Web, чтобы уменьшить количество целей сборки. Это нарушение. Но проекты, основанные на одном из веб-расширений, будут нуждаться в минималистском изменении, чтобы заставить его работать снова. InRequestScope по-прежнему будет доступен для проектов с использованием одного из этих расширений. Пользовательские реализации должны будут добавить поддержку самостоятельно.

Ответ 2

ASP.NET MVC 3 предоставляет службу инъекции зависимостей, которая будет подключаться к любому преобразователю зависимости, который вы решите реализовать. Плагин Ninject MVC 3 очень прост в своей функции, потому что все, что он должен сделать, это реализовать методы разрешения типа, определенные в System.Web.Mvc.IDependencyResolver, и вызвать соответствующие методы Ninject для возврата запрошенного типа.

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

Здесь показан полнофункциональный пример того, как выглядит ручная, совместимая с Ninject IDependencyResolver. Плагин Ninject MVC 3 был бы в основном очень похож:

public class NinjectDependencyResolver : IDependencyResolver
{
    private readonly IKernel _kernel;

    public NinjectDependencyResolver(IKernel kernel) {
        _kernel = kernel;
    }

    public object GetService(Type serviceType) {
        return _kernel.TryGet(serviceType, new IParameter[0]);
    }

    public IEnumerable<object> GetServices(Type serviceType) {
        return _kernel.GetAll(serviceType, new IParameter[0]);
    }
}

Ключевым моментом здесь является то, что ASP.NET MVC не обеспечивает полноценную инфраструктуру инъекций зависимостей; он предоставляет только уровень, необходимый для получения экземпляра требуемого типа посредством контейнера IoC (т.е. Ninject) в определенных точках во всем конвейере запросов ASP.NET MVC (разрешение контроллера, разрешение просмотра и т.д.).

_{Примечание: если какая-либо из терминов, которые я использовал, не совсем точна, сообщите мне.}