Service Locator: por qué suele ser un antipatrón

Un Service Locator es un registro al que un objeto consulta para obtener sus dependencias. Simplifica el acceso, pero oculta esos requisitos en el cuerpo de la clase.

En el artículo anterior vimos que la Inyección de Dependencias (DI) es la forma elegante de que nuestros objetos consigan lo que necesitan: se lo piden al constructor y alguien se lo da.

Pero existe otra forma de conseguir dependencias. Una forma más “autosuficiente”, donde el objeto, en lugar de pedir, busca lo que necesita en un registro central.

Esta técnica se llama Service Locator (Localizador de Servicios).

Aunque resuelve el mismo problema que la DI (desacoplar clases concretas), la forma en que lo hace tiene efectos secundarios peligrosos. Tanto es así, que hoy en día la mayoría de arquitectos de software lo consideran un Anti-Patrón.

Implementación en C#

Veamos cómo luce una implementación simple.

// El Registro Central
public static class ServiceLocator
{
    private static readonly Dictionary<Type, object> _servicios = new Dictionary<Type, object>();

    // Registrar un servicio (se hace al inicio de la app)
    public static void Register<T>(T servicio)
    {
        _servicios[typeof(T)] = servicio;
    }

    // Obtener un servicio (lo usa el cliente)
    public static T Get<T>()
    {
        try 
        {
            return (T)_servicios[typeof(T)];
        }
        catch (KeyNotFoundException)
        {
            throw new Exception($"El servicio {typeof(T).Name} no ha sido registrado.");
        }
    }
}

Ahora, veamos cómo lo usa una clase cliente. Fíjate en la diferencia con la Inyección de Dependencias:

public class GestorPedidos
{
    private ILogger _logger;
    private IDatabase _db;

    public GestorPedidos()
    {
        // ❌ El constructor está vacío de parámetros,
        // pero por dentro está BUSCANDO las dependencias activamente.
        _logger = ServiceLocator.Get<ILogger>();
        _db = ServiceLocator.Get<IDatabase>();
    }

    public void Procesar()
    {
        _logger.Log("Procesando pedido...");
        _db.Guardar();
    }
}

¿Por qué se considera un Anti-Patrón?

A simple vista parece cómodo. No tenemos constructores con 5 parámetros. Simplemente hacemos Get<T>() donde queramos. Pero esta comodidad se paga cara.

Oculta las Dependencias (APIs Mentirosas)

Este es el mayor pecado. Si miráis la definición de la clase:

public class GestorPedidos 
{
    public GestorPedidos() { ... }
}

El constructor nos dice: “Hola, soy GestorPedidos y no necesito nada para funcionar”. ¡Es mentira!

Si intentas instanciar esta clase sin configurar previamente el localizador global, la aplicación fallará en tiempo de ejecución. La inyección de dependencias hace esos requisitos explícitos en el constructor.

Dificulta los Unit Tests

El Service Locator suele ser una clase estática (Singleton). El estado estático es el enemigo de los tests.

• Si un test registra un “Mock de Base de Datos” en el Locator, ese estado se queda ahí.
• El siguiente test podría fallar porque espera una base de datos real y se encuentra el Mock del test anterior.
• No puedes correr tests en paralelo.

Errores en Tiempo de Ejecución vs Compilación

Con Inyección de Dependencias por constructor, si olvidas pasar un parámetro, el código no compila. El compilador te avisa.

Con Service Locator, el código compila perfectamente. El error saldrá el viernes a las 18:00 en producción cuando el código intente recuperar un servicio que nadie registró.

Service Locator vs Dependency Injection

Para cerrar, una comparativa rápida para que no queden dudas:

El Service Locator es como la comida rápida: cómodo y fácil al principio, pero si abusas de él, tu salud (la del código) se resentirá a largo plazo.