Service Locator 디자인 패턴 구현

[gyuwon]

Service Locator 패턴은 몇 가지 단점으로 인해 많은 공격을 받는 의존성 역전 기법이지만 생성자 주입만으로는 해결하기 어려운 몇 가지 상황에 요긴하게 사용될 수 있습니다. Reactive-MVVM은 기본적인 Service Locator 구현체를 제공하고 코드 품질을 저해하지 않는 절제된 범위에서 사용합니다.

[jwChung]

아 이 부분 벌써 진행 중이시군요.
말씀하신 "생성자 주입만으로는 해결하기 어려운 몇 가지 상황"에 팩토리 또는 퍼사드 패턴으로는 해결되지 못할까요?

[gyuwon]

@jwChung 댓글을 이제야 확인했네요. 팩토리도 퍼사드도 inject 되거나 locate 되어야 서비스될 수 있지 않을까요? 예를 들어 ReactiveCommand<T> 클래스는 주 스레드 스케줄러(IPlatform.MainThreadScheduler)를 사용합니다. 이것이 생성자 주입을 사용하지 않는 상황에서 팩토리나 퍼사드로 어떻게 해결될 수 있을까요?

[gyuwon]

@jwChung 상황이 조금 달라졌습니다. ReactiveCommand<T>의 직접적인 스케줄러(IScheduler) 지원 기능을 보류하게 되었습니다. 그러다보니 Service Locator와 관련된 요구가 당장은 없게 되었네요. 불필요한 코드가 있을 필요가 없다고 판단되어 우선은 Service Locator와 관련된 코드를 제거하겠습니다. 그렇지만 그것과는 별개로 팩토리나 퍼사드와 관련된 논의는 좀 더 이어갔으면 합니다.

[jwChung]

@gyuwon

1. 생성자 주입을 사용하지 못하는 이유가 무엇인지요?
   제가 생각했던 것은 Func<Action<object>, Func<object, bool>, ICommand> 같은 팩토리를 뷰모델로 생성자로 주입하거, 아니면 커멘트 객체 생성을 좀 더 추상화한 퍼사드를 주입하는 것이 어떨까였습니다.

2. 아래와 같은 접근도 불가능한가요?

   public ICommand FooCommand =>
       new Command(
           x => {},
           x => true,
           new SomeScheduler(SynchronizationContext.Current));

3. 위 1, 2번 둘다 사실 좋은 코드는 아닌 것 같습니다.
   1번의 경우는 팩토리가 주입될 수 있다하더라도, 예를들어 하나의 커멘드 객체를 만들려고 팩토리를 주입하는 것도 문제고,
   2 번이 된다하더라도 new 생성자로 구체클래스를 생성하고 있으니 이것도 문제네요.
   문제의 근원은 커멘드 객체를 뷰모델에서 생성하고 있는게 아닐까 합니다. 그보다 뷰모델로 조립된 커멘드 객체를 주입하는 것이 문제 해결책 같은데요. 아래와 같이 [BindingCommand] 같은 특성을 이용하여 이름 컨벤션(Can커멘드명, 커멘드명Async) 또는 또 다른 특성을 이용하여 SaveCommand와 메소드(CanSave, SaveAsync)를 bind해주면 어떨까 하는 생각해봤습니다. 그래서 ViewModel이 생성되면 기본적으로 [BindingCommand]특성을 검사하여 ICommand 객체를 Setter 주입하는 것으로요.

   public class ViewModel
   {
       [BindingCommand]
       public ICommand SaveCommand{ get; set;}
   
       public bool CanSave(int parameter)
       {
           return true;
       }
   
       public Task SaveAsync(int parameter)
       {
           return Task.FromResult<object>(null);
       }
   }

[gyuwon]

@jwChung 1, 2번은 좋지 않다고 말씀하신 그대로가 제 생각이고요, 참고로 3번은 몇 년전 교보문고의 e서재 프로젝트에서 제가 만든 프레임워크에서 사용한 방식입니다. 보여주신 방식도 작동했고 더 생략한 문법을 지원하기도 했습니다. MVVM 패턴을 사용하면서 늘어나는 코드가 아주 짜증났었거든요.

// SomeViewModel creates 'SaveCommand' command automatically and dynamically.
public class SomeViewModel : ViewModel
{
    public bool CanSave(object parameter)
    {
        return true;
    }

    public void Save(object parameter)
    {
    }
}

히지만 이런 방식을 사용하더라고 개별 서비스는 어디선가는 제공되어야 합니다. 이 때 지난 번에 말씀드린 것처럼 상위 수준의 뷰모델이 하위 수준의 뷰모델(상위 수준의 뷰모델이 생성하는)이 사용하는 서비스에 대해 알아야 하느냐는 겁니다. 지난 번에는 피드 뷰모델과 항목 뷰모델, 그리고 IClipboard 서비스가 그 예였죠.

public class ItemViewModel
{
    private readonly IClipboard _clipboard;

    // Yes, I need a clipboard service.
    public ItemViewModel(IClipboard clipboard, ItemModel model)
    {
        _clipboard = clipboard;
    }

    public void ExecuteCopyUriCommand(object parameter)
    {
        _clipboard.Copy(GetUri());
    }
}

public class FeedViewModel
{
    private readonly IClipboard _clipboard;

    // Why should I know about IClipboard?
    public FeedViewModel(IClipboard clipboard)
    {
        _clipboard = clipboard;
    }

    private void OnItemsLoaded(IEnumerable<ItemModel> models)
    {
        var viewModels = models.Select(m => new ItemViewModel(_clipboard, m)).ToList();
    }
}

이 문제를 팩토리나 퍼사드를 사용해서 해결하는 것도 바람직해 보이지는 않습니다. 프로그램이 너무 복잡해지거든요. 테스트는 좀 쉬워질런지 모르겠습니다. 하지만 프로덕션 코드는 이해하기 어려워지고 유지보수성도 낮아지지 않을까요? FeedViewModel에 ItemViewModel에 대한 팩토리 함수가 주입되었다고 가정합니다. 아직까지는 적당한 수준이라고 예상됩니다. 그런데 둘 사이와 유사한 관계가 ItemViewModel과 또 다른 뷰모델 사이에 있다고 생각해보면 코드를 유지보수해야 할 때에 팩토리 함수의 정체를 파악하는 데에만 큰 비용이 들어갈겁니다. 함수가 아닌 인터페이스를 사용하면 코드 추적이 좀 쉬워질 수는 있겠지만 타입이 너무 늘어나는 문제가 발생하죠.

[jwChung]

글쎄요 제가 @gyuwon 님이 말씀하시는 것을 잘 이해 못하고 있는건지 모르겠네요. 말씀하신 대로 ICommand와 IClipboard는 다른 얘기네요.

아래 코드를 이렇게 생각하신다는 말씀이신거죠?

이 문제를 팩토리나 퍼사드를 사용해서 해결하는 것도 바람직해 보이지는 않습니다. 프로그램이 너무 복잡해지거든요. 테스트는 좀 쉬워질런지 모르겠습니다. 하지만 프로덕션는 이해하기 어려워지고 유지보수성도 낮아지지 않을까요?

public class ItemViewModel
{
    private readonly IClipboard _clipboard;

    // Yes, I need a clipboard service.
    public ItemViewModel(IClipboard clipboard, ItemModel model)
    {
        _clipboard = clipboard;
    }

    public void ExecuteCopyUriCommand(object parameter)
    {
        _clipboard.Copy(GetUri());
    }
}

public class FeedViewModel
{
    private readonly IClipboard _viewModelFactory;

    public FeedViewModel(Func<ItemModel, ItemVeiwModel> viewModelFactory)
    {
        _viewModelFactory = viewModelFactory;
    }

    private void OnItemsLoaded(IEnumerable<ItemModel> models)
    {
        var viewModels = models.Select(viewModelFactory.Invoke).ToList();
    }
}

public static void Main(string[] args)
{
    IClipboard clipboard = new ConcreteClipboard();
     var feed = new FeedViewModel(m => new ItemViewModel(clipboard, m));
}