He estado mirando el Common Service Locator como una forma de abstraer mi contenedor de IoC pero me he dado cuenta de que algunas personas están en contra de este tipo de esto.¿Cuándo utilizaría el localizador de servicios comunes?
¿La gente lo recomienda nunca? Siempre usándolo? o a veces usándolo? Si a veces, ¿en qué situaciones lo usaría y en qué situaciones no lo usaría?
Imagine que está escribiendo código de biblioteca para ser utilizado por desarrolladores de terceros. Su código debe ser capaz de crear objetos de servicio que estos desarrolladores proporcionan. Sin embargo, no sabe qué contenedor de IoC usará cada uno de los llamantes.
El Localizador de servicios comunes le permite hacer frente a lo anterior sin forzar un IoC determinado a sus usuarios.
Dentro de su propia biblioteca es posible que desee registrar sus propias clases en el IoC, ahora se vuelve mucho más difícil ya que necesita elegir un IoC para su propio uso que no se interponga en el camino de quienes lo llaman.
Solo agregaría que puede verse obligado a utilizar CSL también cuando simplemente no tiene una raíz de composición común o está fuera de su control. Un ejemplo sería un validador de certificado personalizado en el servicio WCF. –
Últimamente he leído algo sobre el concepto de localizador de servicios. Es una forma de ayudar a reducir el acoplamiento, pero requiere el acoplamiento del código al localizador, no el contenedor que respalda el localizador, sino el localizador mismo. Es un intercambio, pero puede ser beneficioso en la situación correcta.
Una situación en la que puede ser útil es cuando tienes un código que no usa DI, como el código heredado. Ahora estoy en este barco. Incorporar los objetos requeridos a través de SL, en lugar de crearlos directamente, permite agregar algo de abstracción. Lo veo como un paso intermedio entre SL y DI/IoC.
Con el código heredado, es posible que no pueda usar la inyección de constructor; la inyección de propiedad puede ser más adecuada en ese momento. –
La biblioteca de Localizador de servicios comunes no se trata solo del patrón Localizador de servicios, ya que traté de explicarlo en mi respuesta. – Steven
Noté que uno de los argumentos en contra del uso de CSL es falso, porque los desarrolladores piensan que esta biblioteca solo es capaz de hacer el patrón de Localizador de servicios. Sin embargo, este no es el caso, porque también es fácil de usar con el patrón de Inyección de Dependencia.
Sin embargo, la biblioteca CSL se diseñó especialmente para diseñadores de frameworks que necesitan permitir a los usuarios registrar dependencias. Debido a que la biblioteca llamará al CSL directamente, desde la perspectiva del marco estamos hablando del patrón SL, de ahí su nombre.
Como diseñador de frameworks, tomar una dependencia del CSL no debería tomarse a la ligera. Para la usabilidad de su marco, normalmente es mucho mejor tener su propio mecanismo DI. Un mecanismo muy común es configurar dependencias en el archivo de configuración. Este patrón se usa en todo el framework .NET. Casi todas las dependencias pueden ser reemplazadas por otras. El patrón de proveedor de .NET se basa en esto.
Cuando usted, como diseñador de marcos, toma una dependencia del CSL, será más difícil para los usuarios usar su aplicación. Los usuarios deberán configurar un contenedor IoC y conectarlo al CSL. Sin embargo, no es posible que el marco valide la configuración como se puede hacer al usar el sistema de configuración .NET, que tiene todo tipo de soporte de validación.
+1 - esta es la única respuesta perspicaz aquí. – MattDavey
Si tiene un código de biblioteca que necesita servicios y este código podría alojarse en el contexto de un framework/runtime más grande, el framework/runtime necesitaría proporcionar un mecanismo donde pueda ejecutar algún código personalizado al inicio donde puedes inicializar tu contenedor y registrar dependencias. Un buen ejemplo de dónde CSL puede ser problemático es cuando se usa en el contexto de MSCRM. Puede ejecutar lógica de negocios personalizada registrando complementos que el marco MSCRM ejecuta en ciertos eventos. El problema con el que se encuentra es dónde ejecuta la lógica de registro ya que no hay ningún evento de "inicio" al que pueda suscribirse para configurar su contenedor DI.Incluso si pudiera configurar de algún modo su DI, tendría que colocar las bibliotecas CSL y DI en el GAC, ya que es la única forma de llamar a un código de terceros desde un complemento (un elemento más para agregar a su lista de comprobación de implementación). En escenarios como este, es mejor que tenga sus dependencias como parámetros de constructor que el código de llamada puede inicializar como lo considere apropiado (mediante la inyección del constructor o manualmente "actualizando" la implementación de la interfaz adecuada).
¿Está buscando escenarios de uso para el Localizador de servicios comunes específica o más generalmente para el patrón de localizador de servicios? Los términos no son necesariamente intercambiables ... – MattDavey