¿Continúa el soporte Ninject en ASP.NET MVC 6?

He estado usando Ninject durante mucho tiempo, y realmente me gusta, pero me enfrento a una elección difícil desde el lanzamiento de ASP.NET 5 y MVC 6 .

Básicamente, fuera de la puerta, Microsoft ha revelado su propio sistema de dependency injection; Cuál es uno que, hasta donde sé, ha recibido muchas críticas. Pero mi mayor problema radica en cómo afecta a otras bibliotecas.

De otra pregunta que hice y otros recursos en línea , parece que Ninject no funciona de la caja con MVC 6. Aunque hay una “solución” en forma de una biblioteca detallada Microsoft.Framework.DependencyInjection.Ninject and Ninject . Esto es aún más complicado porque esa biblioteca requiere agregar https://www.myget.org/F/aspnetmaster/ a su lista de feeds NuGet .

He hecho algunas excavaciones y encontré dónde se aloja esta biblioteca; Se ve bien, parece funcionar bien a partir de lo que puedo decir, pero hay algunas cosas que me preocupan.

  • La biblioteca realmente no parece estar encabezada por los creadores de Ninject
  • La biblioteca está enterrada bastante profundamente en un oscuro repository
  • Los recursos reales de Ninject en línea nunca lo mencionan

Básicamente, estoy muy preocupado de que este sea un tipo de asistente de banda, y ese soporte para Ninject (e incluso otras bibliotecas de contenedores) está desapareciendo. ¿Hay alguna información oculta que no estoy descubriendo?

  • La biblioteca realmente no parece estar encabezada por los creadores de Ninject

Esa biblioteca, y parecería que estas también , parecen ser muestras creadas por Microsoft de proveedores de Inyección de Dependencia que se eliminaron en beta7 . Tenga en cuenta que el enlace a DI en MVC 6 al que hace referencia su pregunta original dice lo siguiente;

Estos adaptadores de contenedor DI son temporales y están ahí para referencia; esperamos que eventualmente sean eliminados y reemplazados por los respectivos propietarios de contenedores.

Como deberían ser Microsoft no debería ser responsable de mantener proveedores de terceros.

  • La biblioteca está enterrada bastante profundamente en un oscuro repository

Si no lo sabe, ASP.NET 5 aún está en desarrollo. Beta 7 está disponible en Nuget como versión preliminar, pero también hay otras fonts;

Estas fonts son mantenidas por Microsoft.

  • Los recursos reales de Ninject en línea nunca lo mencionan

Al igual que con cualquier desarrollo nuevo, los proveedores de bibliotecas de terceros deben determinar cuándo (si es que lo hacen) proporcionarán implementaciones de sus productos que admitan la nueva base de código. Para algunos, se verá como más eficiente esperar hasta que se publique oficialmente el nuevo marco, ya que es muy probable que se produzcan cambios en la API hasta ese momento. Si el soporte se implementará en absoluto es, por supuesto, hasta los recursos de los proveedores, y / o en el caso de la comunidad de código abierto.

Existe una discusión entre los mantenedores de las bibliotecas DI existentes, ya sea para construir, mantener y soportar un adaptador para el nuevo sistema DI integrado de ASP.NET. Los mantenedores de Autofac han confirmado que crearán y admitirán un adaptador, mientras que el equipo de Ninject ha estado en silencio , y otros equipos como el equipo Simple Injector (que me incluye) han explicado que no admitirán un adaptador.

Personalmente, creo que la biblioteca DI incorporada de ASP.NET Core es una biblioteca DI agradable y limpia, pero está limitada a aplicaciones simples. Como expliqué aquí , no se admiten muchas características que se requieren para desarrollar aplicaciones mantenibles basadas en los principios SÓLIDOS. Sin embargo, al igual que la biblioteca de Unity DI hace un par de años, creo que este contenedor integrado realmente podría provocar que los desarrolladores comiencen a usar la dependency injection, que es una victoria para nuestra industria.

Estas limitaciones hacen que el contenedor integrado sea especialmente adecuado para configurar y extender el propio sistema ASP.NET. Para crear aplicaciones grandes mantenibles, deberá usar una biblioteca DI diferente. Esto por supuesto está bien; Tendrás que elegir las herramientas adecuadas para el trabajo.

Desafortunadamente, hasta ahora, el equipo de ASP.NET ha comunicado públicamente que el uso de una biblioteca de DI diferente significa que tendrá que escribir / usar un adaptador. Desafortunadamente, este es el mensaje incorrecto IMO, porque la mayoría de las bibliotecas DI son incompatibles con la API presentada por el contenedor integrado (como expliqué aquí y aquí en detalle). Solo Autofac parece estar razonablemente sincronizado, lo que explica por qué el equipo de Autofac elige mantener un adaptador. Pero tenga en cuenta que incluso Autofac ha demostrado ser incompatible con la abstracción que definió Microsoft, y ellos (al igual que StructureMap) tuvieron que hacer grandes cambios en sus productos para incluso poder cumplir con la abstracción. Y los mantenedores de Autofac están severamente frustrados sobre todo el proceso y la abstracción en general. Y como expliqué aquí , incluso la implementación de adaptador provisto por ASP.NET de Ninject está rota.

Este mensaje del equipo de ASP.NET para usar un adaptador es IMO un gran error, porque esto ahoga la innovación (mientras que la biblioteca DI no lo hace, es solo otra biblioteca DI). El equipo de ASP.NET está promoviendo un modelo donde los componentes de su aplicación y el sistema ASP.NET (y todos los demás subsistemas que se agregarán en el futuro) se registrarán en su contenedor personalizado. Es mucho más razonable y práctico mantener la configuración de su aplicación separada de la configuración del sistema ASP.NET (como se explica aquí ).

Debido a esto, el uso de un adaptador para cualquier contenedor me resulta inútil. Como se muestra aquí , es muy fácil instalar tu propio contenedor DI, manteniéndolo completamente separado de los registros de ASP.NET. Esto significa que no necesita soporte para Ninject para poder usar efectivamente Ninject en un proyecto ASP.NET Core. Lo único que Ninject debe hacer es crear una versión que sea compatible con .NET Core (en caso de que su producto deba ejecutarse en esa nueva plataforma).

ACTUALIZACIÓN : “Ninject 3.3.0 fue lanzado el 26 de septiembre de 2017 y ahora se dirige a .NET Standard 2.0 y por lo tanto también se ejecuta en .NET Core 2.0”. fuente

Entonces, en pocas palabras, no estoy seguro de que el soporte “se esté extinguiendo”, aunque algunos mantenedores de DI (como el equipo de Simple Injector, y probablemente Castle Windsor y Ninject también) han elegido no construir, mantener y soportar un adaptador implementación para ASP.NET Core, porque no es necesario, y solo está en camino.

ACTUALIZACIÓN Noviembre 2016

He estado discutiendo algunas mejoras en ASP.NET Core con Microsoft para facilitar el complemento de un contenedor que no tiene un adaptador (eche un vistazo a mi repository de ejemplo y especialmente a los Startup.cs del proyecto de ejemplo Ninject ) , pero hasta ahora Microsoft parece detener el progreso porque (como Fowler se declara a sí mismo) su ” predisposición hacia los contenedores ajustados [está] nublando [su] visión”.