¿Cuáles son las ventajas y desventajas de utilizar un Localizador de servicios en comparación con un singleton? He leído que los singletons son malos, pero me pregunto si el Service Locator sería en general una mejor forma de hacer las cosas.Singleton Vs ServiceLocator
Ambos enfoques son malos en cuanto a que no es obvio desde el contrato de clase cuáles son sus 'dependencias'. Es decir,
private void foo()
{
var x = SomeSingleton.Instance.GetX();
var y = ServiceLocator.GetService<IProvider>().GetY();
}
tiene referencias a SomeSingleton y IProvider profundamente enterrado en algún lugar dentro.
Sin embargo, en comparación con el enfoque de Singleton pura, localizadores de servicios son por lo general mucho mejor en cuanto a que permiten una configuración más sencilla centralizada, gestión de vida, etc. También permiten una mejor capacidad de prueba (siempre que pueda llamadas simuladas a GetService<T>), de acoplamiento inferior , separación de preocupaciones, etc.
si la capacidad de prueba es una preocupación, el uso del localizador de servicios es mucho mejor que los singleton puros.
Iría tan lejos como para considerar ambos antipatrones, pero estoy de acuerdo en que Service Locator es marginalmente preferible. La mejor solución sería implementar una Inyección de Dependencia adecuada. –
por lo que entiendo por DI, ¿no requeriría que todos los objetos que solían acceder al singleton directamente tengan una referencia al objeto ex singleton? – djcouchycouch
Sí, debe darles como parámetros al constructor (si usa la inyección de constructor, esto se conoce generalmente como "Declarar sus dependencias"). Para facilitar un poco las cosas, puede usar los contenedores de Inversión de control. Eche un vistazo a Google Guice. –