9

Me pregunto cómo debo almacenar/referenciar mi contenedor de inyección de dependencia. ¿Está bien tener un contenedor como propiedad estática en una clase estática? ¿O debería tener el contenedor como una variable de instancia en la aplicación? Me pregunto cuáles son los pros y los contras de cada opción, y cuál es la mejor práctica para esto en aplicaciones web, mvc, de consola y de Windows.¿Dónde debo almacenar una referencia a mi contenedor DI?

+0

duplicado: http://stackoverflow.com/questions/644747/autofac-in-web-applications-where-should-i-store-the-container-for-easy-access http://stackoverflow.com/ preguntas/277438/abstracting-ioc-container-behind-a-singleton-doing-it-wrong http://stackoverflow.com/questions/480286/best-practices-for-ioc-container http://stackoverflow.com/ preguntas/367178/use-of-ioc-containers-specific-windsor http://stackoverflow.com/questions/1612682/typical-ioc-container-usage-passing-data-down-the-line –

+1

¡Gracias a todos! Perdón por todos los duplicados. Supuse que se trataba de un duplicado, pero no estaba seguro de cómo formular mi pregunta para encontrarlos. –

Respuesta

5

Recomiendo almacenarlo como una variable de instancia en la aplicación. Usar una propiedad estática, convirtiéndolo en un singleton globalmente accesible, oculta la dependencia de su aplicación, ¡que es una de las cosas de las que trata de alejarse usando un contenedor de inyección de dependencia en primer lugar!

Habiendo dicho esto, si su marco de trabajo le dificulta el acceso a su instancia de aplicación, no sería el fin del mundo usar una variable estática.

1

Estoy de acuerdo con el Sr. Sternal en esto. Una cosa a considerar es que algunos contenedores DI implementan IDisposable, por lo que es probable que desee deshacerse del contenedor en la terminación normal del programa. Consulte How do you reconcile IDisposable and IoC?

También tenga en cuenta que a menudo es mejor evitar dispersar dependencias en el contenedor DI en toda su aplicación. En otras palabras, trate de evitar que el contenedor esté disponible globalmente (Singleton, propiedad estática o incluso inyectado) para usar como Service Locator.

En su lugar, puede usar la capacidad del contenedor para resolver dependencias de dependencias. Por ejemplo, puede crear el contenedor al inicio de la aplicación y usarlo para construir su Modelo (en MVC). El modelo puede depender de un repositorio y un servicio web. El repositorio puede depender de un registrador. El contenedor resolverá todos estos cuando se construya el modelo. Si su modelo necesita crear instancias de dependencias sobre la marcha, inyecte una fábrica en él.

+1

Estoy de acuerdo, y me gusta cómo un afiche lo puso en uno de los engañados que desenterró Mauricio: "Coloque el contenedor de COI en el nivel más alto/punto de entrada en el proceso y úselo para inyectar dependencias en todo debajo de él". (http://stackoverflow.com/questions/480286/best-practices-for-ioc-container) –

+0

@Jeff - Buena cita; simple y al grano. También hay una respuesta excelente de Thorsten Lorenz en este enlace (también de Mauricio): http://stackoverflow.com/questions/480286/best-practices-for-ioc-container – TrueWill

+0

Si coloca el contenedor al más alto nivel, esto presumiblemente crea una necesidad de mantener una referencia a su ensamblaje de nivel más bajo que requiere inyección (tal vez acceso a datos). Esto me molesta un poco :( – dougajmcdonald

Cuestiones relacionadas