Reemplazo de Spring.Net IoC con otro contenedor (por ejemplo, Ninject)

Tengo curiosidad por saber si es posible reemplazar Contenedor de IoC incorporado de Spring.Net con Ninject. Usamos Ninject en mi equipo para IoC en nuestros otros proyectos, así que me gustaría continuar usando ese contenedor si es posible.Reemplazo de Spring.Net IoC con otro contenedor (por ejemplo, Ninject)

¿Esto es posible? ¿Alguien ha escrito un adaptador Ninject-Spring.Net?

Editar

me gustan muchas partes del paquete Spring.Net (el acceso a los datos, transacciones, etc.) pero no me gusta mucho el contenedor de inyección de dependencias. Me gustaría sustituir eso con Ninject

Gracias

Fuente

2010-01-10 Jeffrey Cameron

Jeffrey, ¿podría darme un ejemplo de lo que está tratando de hacer? No entiendo tu punto, por qué/dónde/cómo quieres mezclar los 2 contenedores. Si su código es completamente independiente del contenedor, entonces no tendrá ningún problema para utilizar ninguno de los contenedores para realizar el cableado.

Fuente

2010-01-13 06:36:00

Erich, no quiero mezclar los dos, quiero reemplazar por completo el contenedor Spring.Net con Ninject (lo utilizamos en otros proyectos y prefiero su API simple y fluida). Pregunta complementaria: ¿está escrito Spring.Net en torno a la propiedad o la inyección del constructor en general? Algunas de las clases que he analizado parecen estar configuradas con inyección de propiedad. –

Déjenme aclarar cuando veo de dónde viene el malentendido. Me gusta, por ejemplo, los contenedores DAO y ADO.Net utilizados en Spring.Net, pero quiero poder configurar esos componentes sin utilizar el contenedor proporcionado como parte de Spring.Net. –

Jeffrey, está perfectamente bien utilizar las otras bibliotecas de Spring.NET por separado del contenedor IoC. Con respecto a la inyección de Constructor vs. Propiedad, Spring.NET le permite elegir entre los dos por objeto. Cuando se trata de objetos de cableado automático, incluso puede configurar el contenedor de Spring para buscar primero un constructor y, si no encuentra ninguno o puede satisfacerlo, intente inyectar la propiedad en su lugar. En cuanto a la API simple y fluida, es posible que desee consultar mi nuevo proyecto Spring.Config http://eeichinger.blogspot.com/2009/12/merry-xmlless-codeconfig-for-springnet.html. –

no puedo hablar específicamente acerca de la conversión a Spring.NET Ninject, pero, en general, todo el código de aplicación debe ser escrito para ser DI-Container agnóstico.

La mejor manera de pensar en Contenedores DI es el Hollywood Principle. En términos DI, se convierte en no llame al Contenedor DI, lo llamará.

En otras palabras, la mejor aplicación de DI es el uso de patrones simples, tales como Constructor de inyección y Abstract Factory.

La mayoría de los Contenedores DI que valen la pena por su inherente comprensión de estos patrones, por lo que no se necesita ningún especial, DI contenedor específico, saltar a través de aros.

Esto también significa que, idealmente, solo debe tener el código específico de DI Container en un solo archivo en su aplicación. Este lugar se llama Composition Root, y aquí es donde DI Container conecta todo el gráfico de objeto y se quita.

Si sigue este principio, puede cambiar fácilmente un contenedor DI por otro.

Los siguientes mensajes tienen más detalles:

Fuente

2010-01-10 20:58:24

+1. De acuerdo: definitivamente desea evitar pasar el contenedor para utilizarlo como un localizador de servicios. – TrueWill

Estoy de acuerdo con sus declaraciones, solo quería saber si Spring.Net se desarrolló de esa manera. No tengo ninguna experiencia con eso y no quiero perder tiempo investigando si no puedo usar Ninject con él –

que quería decir todo lo que dije en mi otra respuesta. Sin embargo, también me doy cuenta de que si usa actualmente use Spring.NET como un localizador de servicios (es decir, tiene código salpicado en su base de códigos que consulta el contenedor), esa respuesta puede no ser muy útil.

Si este es el caso, puede encontrar útil el proyecto Common Service Locator. Es un proyecto de código abierto que intenta abstraer los Localizadores de servicios específicos, escondiéndolos detrás de una interfaz común.

Si bien no parecen tener una implementación de Ninject, sí tienen una implementación de Spring.NET, así que tal vez eso puede llevarte hasta la mitad.

Para el registro, considero Servicio de Localización de un anti-patrón, y encontrar que el Servicio de Localización Común es la respuesta equivocada a un problema equivocado. En mi opinión, es completamente redundante, pero puede ser útil para usted como un paso intermedio.

Fuente

2010-01-10 21:15:23

Hola Mark, agradezco tus respuestas muy detalladas e informativas, pero tengo el mismo comentario que antes: Todo lo que realmente quiero saber es si alguien ha usado Ninject con Spring.Net y/o cuál fue su experiencia, cómo lo conectaron, etc. –

Reemplazo de Spring.Net IoC con otro contenedor (por ejemplo, Ninject)

Respuesta

Cuestiones relacionadas