ninject asp.net-core-mvc

¿Soporte continuo de Ninject en ASP.NET MVC 6?



asp.net-core-mvc (2)

He estado muy feliz 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 inyección de dependencia; Cuál es, que yo sepa, 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 forma inmediata con MVC 6. Aunque hay una "solución" dada 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 fuentes NuGet .

Investigué un poco y descubrí dónde está alojada esta biblioteca; Se ve bien, parece funcionar bien por lo que puedo decir, pero hay algunas cosas que me preocupan.

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

Básicamente, me preocupa mucho que se trate de una especie de curita, y que el soporte para Ninject (e incluso otras bibliotecas de contenedores) se esté extinguiendo. ¿Hay alguna información oculta que no estoy descubriendo?

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

Esa biblioteca, y parece que también estas , 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 allí para referencia; esperamos que eventualmente sean eliminados y reemplazados por los respectivos propietarios de los contenedores.

Como deberían ser. Microsoft no debe ser responsable de mantener proveedores externos.

  • La biblioteca está enterrada bastante profundo en un oscuro repositorio

Si no lo sabe, ASP.NET 5 todavía está en desarrollo. Beta 7 está disponible en Nuget como prelanzamiento, pero también hay otras fuentes que incluyen;

Estas fuentes son mantenidas por Microsoft.

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

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

Hay una discusión entre los mantenedores de las bibliotecas DI existentes, sobre si construir, mantener y soportar un adaptador para el nuevo sistema DI incorporado ASP.NET. Los mantenedores de Autofac han confirmed que crearán y admitirán un adaptador, mientras que el equipo de Ninject ha guardado silent , y otros equipos como el equipo de Simple Injector (que me incluye a mí) han explicado que no admitirán un adaptador.

Personalmente, creo que la biblioteca DI integrada de ASP.NET Core es una biblioteca DI agradable y limpia, pero está limitada a aplicaciones simples. Como expliqué here , no se admiten muchas características que se requieren para desarrollar aplicaciones mantenibles basadas en los principios de SOLID. Sin embargo, al igual que la biblioteca Unity DI hace un par de años, creo que este contenedor incorporado podría en realidad provocar que los desarrolladores comiencen a usar la inyección de dependencia, lo cual es una victoria para nuestra industria.

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

Desafortunadamente, hasta ahora, el equipo de ASP.NET se ha comunicado publicly que usar una biblioteca DI diferente significa que tendrá que escribir / usar un adaptador. Desafortunadamente, este es el mensaje IMO incorrecto, porque la mayoría de las bibliotecas DI son incompatibles con la API presentada por el contenedor incorporado (como expliqué here y aquí en detalle). Solo Autofac parece 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 Microsoft definió, y ellos (al igual que StructureMap) tuvieron que hacer grandes cambios en su producto para poder cumplir con la abstracción. Y los mantenedores de Autofac están muy frustrados por todo el proceso y la abstracción en general. Y como expliqué here , incluso la implementación del adaptador proporcionada por ASP.NET de Ninject está rota.

Este mensaje del equipo de ASP.NET para usar un adaptador es un gran error de la OMI, porque esto sofoca la innovación (mientras que la biblioteca DI en sí no lo hace; es solo otra biblioteca DI). El equipo de ASP.NET está promoviendo un modelo en el que tanto los componentes de la aplicación como 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 here ).

Debido a esto, considero que el uso de un adaptador para cualquier contenedor es bastante inútil. Como lo mostré here , es realmente fácil enchufar su propio contenedor DI, mientras lo mantiene completamente separado de los registros de ASP.NET. Esto significa que no necesita soporte para Ninject para poder usar Ninject de manera efectiva en un proyecto ASP.NET Core. Lo único que debe hacer Ninject 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 se lanzó 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". source

En pocas palabras, no estoy seguro de que el soporte ''esté desapareciendo'', aunque algunos mantenedores de DI (como el equipo de Simple Injector y probablemente Castle Windsor y Ninject también) han optado por no construir, mantener y soportar un adaptador implementación para ASP.NET Core, porque no es necesaria y solo está en el 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 repositorio de ejemplo y especialmente a here ) , pero hasta ahora Microsoft parece retrasar el progreso porque (como dice Fowler) su " sesgo hacia los contenedores conformes [está] nublando [su] visión".