서비스 로케이터

서비스 로케이터^{Service Locator}는 객체가 필요한 의존성을 스스로 직접 요청하여 얻어오는 디자인 패턴입니다. 의존성 주입^{Dependency Injection, DI}과 함께 제어 반전^{Inversion of Control, IoC}을 구현하는 방식 중 하나입니다. 서비스 로케이터 패턴에서는 객체가 중앙화된 서비스 제공자(서비스 로케이터)를 통해 필요한 의존성을 요청하고 얻습니다. 이를 통해 코드의 유연성을 높일 수 있지만, DI에 비해 몇 가지 차이점과 단점이 있습니다.

서비스 로케이터 패턴의 개념

서비스 로케이터란?

서비스 로케이터는 중앙화된 위치에서 다양한 의존성을 관리하고 제공하는 역할을 합니다. 각 객체는 자신이 필요로 하는 의존성을 직접 생성하지 않고, 서비스 로케이터를 통해 요청하여 얻습니다. 서비스 로케이터는 의존성을 관리하고, 요청에 따라 적절한 서비스를 제공하는 중개자 역할을 합니다.

서비스 로케이터의 흐름

서비스 로케이터 패턴을 사용하면 객체는 중앙의 서비스 로케이터에 접근해 의존성을 요청합니다. 이 방식에서는 객체가 스스로 의존성을 직접 요청하므로, 코드에서 의존성을 명시적으로 관리합니다.

• 객체가 서비스 로케이터에 접근합니다.
• 서비스 로케이터는 등록된 서비스 목록에서 요청된 의존성을 찾아 반환합니다.
• 객체는 반환된 의존성을 사용하여 자신의 작업을 수행합니다.

서비스 로케이터 패턴 예시

public interface IServiceLocator
{
    T GetService<T>();
}
public class ServiceLocator : IServiceLocator
{
    private readonly Dictionary<Type, object> _services = new Dictionary<Type, object>();
    public void Register<T>(T service)
    {
        _services[typeof(T)] = service;
    }
    public T GetService<T>()
    {
        return (T)_services[typeof(T)];
    }
}
public class MyService
{
    private readonly IRepository _repository;
    public MyService(IServiceLocator serviceLocator)
    {
        _repository = serviceLocator.GetService<IRepository>();
    }
    public void DoSomething()
    {
        var data = _repository.GetData();
        Console.WriteLine(data);
    }
}

• ServiceLocator 클래스는 의존성 관리 역할을 합니다. Register<T>() 메서드를 통해 의존성을 등록하고, GetService<T>() 메서드를 통해 의존성을 반환합니다.
• MyService 클래스는 IRepository 의존성을 직접 생성하지 않고, 서비스 로케이터를 통해 요청하고 주입받습니다.

서비스 로케이터 패턴의 장단점

장점

• 중앙화된 의존성 관리: 서비스 로케이터는 모든 의존성을 중앙에서 관리하므로, 의존성 관리가 한 곳에서 이루어집니다.
• 코드 유연성: 서비스 로케이터를 통해 객체는 필요에 따라 다양한 의존성을 요청할 수 있으며, 쉽게 다른 구현체로 변경할 수 있습니다.
• 지연 초기화: 객체가 필요할 때 의존성을 가져오는 방식이므로, 지연 로딩^{Lazy Loading}이 가능하여 성능 최적화를 할 수 있습니다.

단점

• 결합도 증가: 객체가 서비스 로케이터에 직접적으로 의존하기 때문에, 객체와 서비스 로케이터 간의 결합도가 높아집니다. 이는 코드의 재사용성을 떨어뜨릴 수 있습니다.
• 테스트 복잡성: 테스트 시 서비스 로케이터의 존재 때문에 Mocking이나 테스트 객체 주입이 더 복잡해질 수 있습니다. DI 방식에 비해 테스트 작성이 덜 유연합니다.
• 숨겨진 의존성: 서비스 로케이터를 사용하면 코드에서 명시적으로 의존성을 주입받지 않고, 런타임에 의존성을 요청하므로, 의존성이 코드 상에서 명확히 드러나지 않습니다. 이로 인해 코드의 가독성이 떨어질 수 있습니다.

의존성 주입과 서비스 로케이터 비교

의존성 주입 vs 서비스 로케이터 패턴

언제 의존성 주입을 사용해야 할까?

• 유연성과 테스트 가능성이 중요한 애플리케이션에서는 의존성 주입이 더 적합합니다. 특히 대규모 시스템이나 모듈 간 결합도가 낮아야 하는 경우, DI 패턴을 사용하면 코드의 유연성과 유지보수성이 크게 향상됩니다.

언제 서비스 로케이터를 사용해야 할까?

• 서비스 로케이터는 지연 초기화가 필요한 경우나, 객체가 특정 상황에서만 의존성을 필요로 하는 경우에 유리합니다. 또한, 의존성이 많지 않은 소규모 시스템이나 빠르게 의존성을 가져와야 하는 경우 서비스 로케이터를 사용할 수 있습니다.

.NET에서의 서비스 로케이터

.NET에서는 IoC 컨테이너와 서비스 로케이터 패턴을 모두 지원하며, IoC 컨테이너가 서비스 로케이터의 역할을 할 수 있습니다. 하지만, .NET Core와 같은 최신 프레임워크에서는 의존성 주입(DI)이 기본적으로 채택되고 선호되는 방식입니다.

.NET Core에서 서비스 로케이터 사용

.NET Core에서도 서비스 로케이터 패턴을 구현할 수 있지만, 기본적으로 제공되는 IoC 컨테이너를 통해 의존성 주입 방식을 사용하는 것이 일반적입니다. 그럼에도 불구하고, 필요할 경우 서비스 프로바이더를 통해 서비스 로케이터처럼 동작할 수 있습니다.

public class MyController : Controller
{
    private readonly IServiceProvider _serviceProvider;
    public MyController(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }
    public IActionResult Index()
    {
        // 서비스 로케이터처럼 동작
        var service = _serviceProvider.GetService<IService>();
        service.DoSomething();
        return View();
    }
}

IServiceProvider와 서비스 로케이터 패턴

.NET Core에서는 IServiceProvider 인터페이스를 통해 IoC 컨테이너에서 서비스를 요청할 수 있습니다. 이를 통해 서비스 로케이터처럼 동작할 수 있지만, 일반적으로 의존성 주입 방식이 더 선호됩니다. 그 이유는 IServiceProvider를 직접 사용하는 방식은 결합도를 높이고 테스트가 어려워질 수 있기 때문입니다.

적합한 사용 사례

서비스 로케이터는 적합한 상황에서 사용될 수 있지만, 대부분의 경우 의존성 주입(DI) 패턴이 더 권장됩니다. 서비스 로케이터는 다음과 같은 경우에 적합할 수 있습니다:

• 플러그인 시스템: 플러그인 구조에서 서비스 로케이터는 필요한 플러그인을 런타임에 동적으로 로드하는 데 유리할 수 있습니다.
• 복잡한 객체 그래프: 의존성이 복잡하게 연결된 경우 서비스 로케이터를 사용해 필요한 객체를 동적으로 로드하는 방식이 도움이 될 수 있습니다.
• 레거시 시스템: DI를 완전히 적용하기 어려운 레거시 시스템에서 서비스 로케이터를 사용하면 의존성 관리를 간소화할 수 있습니다.

맺음말

서비스 로케이터^{Service Locator} 패턴은 객체가 의존성을 직접 요청하여 가져오는 방식으로, 중앙에서 의존성을 관리할 수 있다는 장점이 있습니다. 그러나 결합도가 높아지고, 테스트가 어려워질 수 있는 단점이 있어, 현대적인 소프트웨어 설계에서는 주로 의존성 주입(DI) 패턴이 더 선호됩니다. 특히 .NET Core에서는 DI가 기본적으로 지원되며, 서비스 로케이터 패턴보다는 DI를 통해 의존성을 관리하는 것이 더 일반적입니다.

Buy me a coffee