이 코드를 작성하는 방법은 테스트 가능하지만 누락 된 것이 있습니까?

라는 인터페이스가 IContext있습니다. 이를 위해 다음을 제외하고는 실제로 어떤 일을하는지는 중요하지 않습니다.

T GetService<T>();

이 방법은 응용 프로그램의 현재 DI 컨테이너를보고 종속성을 해결하려고 시도합니다. 상당히 표준이라고 생각합니다.

내 ASP.NET MVC 응용 프로그램에서 생성자는 다음과 같습니다.

protected MyControllerBase(IContext ctx)
{
    TheContext = ctx;
    SomeService = ctx.GetService<ISomeService>();
    AnotherService = ctx.GetService<IAnotherService>();
}

따라서 각 서비스의 생성자에 여러 매개 변수를 추가하는 대신 (응용 프로그램을 확장하는 개발자에게는 실제로 성 가시고 시간이 많이 걸리기 때문에)이 방법을 사용하여 서비스를 받고 있습니다.

지금, 그것은 잘못 느낀다 . 그러나, 내가 현재 내 머릿속에서 그것을 정당화하는 방법은 이것 입니다. 나는 그것을 조롱 할 수 있습니다 .

저 할 수 있어요. IContext컨트롤러를 테스트 하기 위해 조롱하는 것은 어렵지 않습니다 . 어쨌든 나는 :

public class MyMockContext : IContext
{
    public T GetService<T>()
    {
        if (typeof(T) == typeof(ISomeService))
        {
            // return another mock, or concrete etc etc
        }

        // etc etc
    }
}

그러나 내가 말했듯이, 그것은 잘못 느낍니다. 모든 생각 / 학대 환영.

생성자에 많은 매개 변수 대신 하나를 갖는 것이이 디자인의 문제가되는 부분 이 아닙니다 . 언제 까지나 당신 같은 IContext클래스가 아무것도하지만없는 서비스 외관 specificially에 사용 종속 제공, MyControllerBase, 그리고 전체 코드에서 사용되는 일반적인 서비스 로케이터는, 코드의 일부는 이럴 확인합니다.

첫 번째 예가

protected MyControllerBase(IContext ctx)
{
    TheContext = ctx;
    SomeService = ctx.GetSomeService();
    AnotherService = ctx.GetAnotherService();
}

그것의 실질적인 디자인 변경은 아닙니다 MyControllerBase. 이 디자인이 좋고 나쁘다면 당신이 원하는 경우에만 사실에 달려 있습니다

• 확인 TheContext, SomeService그리고 AnotherService항상 모든 mock 객체로 초기화하거나 그들 모두 실물로
• 또는 3 개의 객체를 다르게 조합하여 초기화 할 수 있습니다 (이 경우 매개 변수를 개별적으로 전달해야 함)

따라서 생성자에서 3 대신에 하나의 매개 변수 만 사용하는 것이 합리적 일 수 있습니다.

문제가되는 것은입니다 IContext노출 GetService공공 장소에서 방법을. IMHO 당신은 이것을 피해야하며, 대신 "공장 방법"을 명시 적으로 유지하십시오. 서비스 로케이터를 사용하여 예제에서 GetSomeServiceand GetAnotherService메소드 를 구현해도 괜찮 습니까? IMHO에 달려 있습니다. 오랫동안 같이 IContext클래스가 바로 이럴 허용 서비스 객체의 명시 적 목록을 제공하는 특정 목적에 대한 간단한 추상 공장을 beeing는 유지합니다. 추상 팩토리는 일반적으로 "접착제"코드이므로 단위 테스트 자체가 필요하지 않습니다. 그럼에도 불구하고 같은 메소드의 맥락에서, GetSomeService실제로 서비스 로케이터가 필요한지, 명시적인 생성자 호출이 더 간단하지 않은지 스스로에게 문의 해야합니다.

따라서 IContext구현이 공개적이고 일반적인 GetService메소드 주위의 래퍼 인 디자인을 고수 할 때 임의의 클래스로 임의의 의존성을 해결하면 모든 것이 @ BenjaminHodgson이 그의 답변에 쓴 것을 적용합니다.

이 디자인은 Service Locator * 로 알려져 있으며 마음에 들지 않습니다. 그것에 대해 많은 논쟁이 있습니다.

Service Locator는 컨테이너에 연결 합니다. 일반적인 의존성 주입 (생성자가 의존성을 명시 적으로 철자하는 곳)을 사용하면 컨테이너를 다른 것으로 간단하게 교체하거나 new-expressions 로 돌아갈 수 있습니다. 그것으로 IContext정말 불가능합니다.

서비스 로케이터는 종속성을 숨 깁니다 . 클라이언트는 클래스의 인스턴스를 구성하는 데 필요한 것을 말하기가 매우 어렵습니다. 당신은 어떤 종류의 필요 IContext,하지만 당신은 또한 만들기 위해 올바른 개체를 반환하는 컨텍스트를 설정해야 MyControllerBase일을. 이것은 생성자의 서명에서 전혀 분명하지 않습니다. 일반 DI로 컴파일러는 필요한 것을 정확하게 알려줍니다. 수업에 많은 의존성이 있다면 리팩토링을 자극하기 때문에 고통을 느껴야합니다 . Service Locator는 잘못된 설계 문제를 숨 깁니다.

서비스 로케이터는 런타임 오류를 발생시킵니다 . GetService잘못된 유형 매개 변수를 사용하여 호출 하면 예외가 발생합니다. 다시 말해, GetService함수는 총 함수가 아닙니다. (총 함수는 FP 세계의 아이디어이지만 기본적으로 함수는 항상 값을 반환해야 함을 의미합니다.) 컴파일러가 도움을 받고 종속성이 잘못되었을 때 알려주는 것이 좋습니다.

서비스 로케이터가 Liskov 대체 원칙을 위반합니다 . 동작은 type 인수에 따라 다르므로 Service Locator는 인터페이스에 무한한 수의 메소드가있는 것처럼 볼 수 있습니다! 이 주장은 여기 에 자세히 설명되어 있습니다 .

Service Locator는 테스트하기가 어렵습니다 . IContext테스트 에 대한 가짜 예를 제시 했지만, 처음에는 해당 코드를 작성하지 않는 것이 좋습니다. 서비스 로케이터를 거치지 않고 가짜 의존성을 직접 주입하십시오.

요컨대, 하지 마십시오 . 많은 의존성을 가진 클래스의 문제에 대한 매혹적인 해결책처럼 보이지만 장기적으로는 인생을 비참하게 만들 것입니다.

_{* Resolve<T>임의의 종속성을 해결할 수 있고 컴포지션 루트뿐만 아니라 코드베이스 전체에서 사용되는 일반적인 방법 으로 Service Locator를 객체로 정의 하고 있습니다. 이것은 Service Facade (작은 알려진 종속성 집합을 묶는 객체) 또는 Abstract Factory (단일 유형의 인스턴스를 만드는 객체-Abstract Factory의 유형 은 일반적이지만 방법 은 아닙니다)와 동일하지 않습니다. .}

Service Locator 안티 패턴에 대한 가장 좋은 주장은 Mark Seemann에 의해 명확 하게 언급되어 있기 때문에 이것이 왜 나쁜 생각인지에 대해서는 너무 많이 언급 하지 않을 것입니다. 또한 Mark 's book을 추천 합니다.

질문에 대답하기 위해 확인하십시오- 실제 문제를 다시 말씀 드리겠습니다 .

따라서 각 서비스의 생성자에 여러 매개 변수를 추가하는 대신 (응용 프로그램을 확장하는 개발자에게는 실제로 성 가시고 시간이 많이 걸리기 때문에)이 방법을 사용하여 서비스를 받고 있습니다.

StackOverflow 에서이 문제를 해결하는 질문이 있습니다. 의견 중 하나에서 언급했듯이 :

가장 좋은 설명 : "생성자 주입의 놀라운 이점 중 하나는 단일 책임 원칙을 위반하는 것이 명백하게 드러난다는 것입니다."

문제의 해결책을 찾기 위해 잘못된 곳을 찾고 있습니다. 수업이 너무 많은시기를 아는 것이 중요합니다. 귀하의 경우에는 내가 강하게 의심 에 "자료 컨트롤러"에 대한 필요가 없다. 실제로 OOP에서는 거의 항상 상속이 필요하지 않습니다 . 행동과 공유 기능의 변화는 인터페이스를 적절히 사용하여 완전히 달성 할 수 있으며, 이는 일반적으로 더 잘 팩토링되고 캡슐화 된 코드를 생성하며, 의존성을 슈퍼 클래스 생성자에게 전달할 필요가 없습니다.

나는 자료 컨트롤러가 위치에 작업 한 모든 프로젝트에서는, 같은 편리한 프로퍼티와 메소드, 공유의 목적을 위해 순수하게 이루어졌다 IsUserLoggedIn()과 GetCurrentUserId(). 중지하십시오 . 이것은 상속의 끔찍한 오용입니다. 대신, 이러한 메소드를 노출하는 컴포넌트를 작성하여 필요한 곳에 의존하십시오. 이러한 방식으로 구성 요소는 테스트 가능한 상태로 유지되며 해당 종속성이 분명해집니다.

다른 것 외에도 MVC 패턴을 사용할 때는 항상 스키니 컨트롤러를 권장 합니다. 여기에서 더 자세히 읽을 수 있지만 패턴의 본질은 간단합니다. MVC의 컨트롤러는 한 가지만 수행해야합니다. 이것은 다시 직장에서의 단일 책임 원칙입니다.

더 정확한 판단을 내리려면 유스 케이스를 아는 것이 실제로 도움이 될 것입니다. 그러나 솔직히 기본 클래스가 팩터링 된 종속성보다 선호되는 시나리오는 생각할 수 없습니다.

다른 사람의 기여를 바탕으로 이에 대한 답변을 추가하고 있습니다. 정말 고마워요 우선 여기에 제 대답이 있습니다 : "아니오, 아무 문제가 없습니다".

Doc Brown의 "Service Facade"답변 이 답변은 내가 찾은 것 (답이 "아니오"인 경우)이 내가하고있는 일에 대한 예 또는 일부 확장 이었기 때문에이 답변 을 수락했습니다. 그는 A) 이름이 있고 B)이를 수행하는 더 좋은 방법이 있다고 제안하면서 이것을 제공했습니다.

Benjamin Hodgson의 "서비스 로케이터"답변 여기에서 얻은 지식에 감사하는 한, "서비스 로케이터"가 아닙니다. "서비스 외관"입니다. 이 답변의 모든 것은 정확하지만 내 상황에는 맞지 않습니다.

USR의 답변

좀 더 자세히 다루겠습니다.

이런 식으로 많은 정적 정보를 포기합니다. 많은 동적 언어와 마찬가지로 런타임에 대한 결정을 연기하고 있습니다. 이렇게하면 정적 검증 (안전), 문서 및 툴링 지원 (자동 완성, 리팩토링, 용도 찾기, 데이터 흐름)을 잃게됩니다.

툴링을 잃지 않고 "정적"타이핑을 잃지 않습니다. 서비스 파사드는 DI 컨테이너에서 구성한 것을 반환합니다 default(T). 그리고 그것이 반환하는 것은 "typed"입니다. 반사가 캡슐화됩니다.

추가 서비스를 생성자 인수로 추가하는 것이 왜 큰 부담이되는지 모르겠습니다.

확실히 "드문"이 아닙니다. 기본 컨트롤러를 사용하고 있으므로 생성자를 변경해야 할 때마다 10, 100, 1000 다른 컨트롤러를 변경해야 할 수도 있습니다.

의존성 주입 프레임 워크를 사용하면 매개 변수 값을 수동으로 전달할 필요조차 없습니다. 그런 다음 다시 한 번 정적 이점을 잃지 만 많은 것은 아닙니다.

의존성 주입을 사용하고 있습니다. 그게 요점입니다.

마지막으로 Benjamin의 답변에 대한 Jules의 의견은 유연성을 잃지 않습니다. 그건 내 서비스 외관. GetService<T>DI 컨테이너를 구성 할 때와 마찬가지로 다른 구현을 구별하기 위해 많은 매개 변수를 추가 할 수 있습니다 . 그래서 예를 들어, 내가 바꿀 수 GetService<T>()하기 위해 GetService<T>(string extraInfo = null)이 "잠재적 인 문제"를 해결하기 위해.

어쨌든 모두에게 다시 한번 감사드립니다. 그것은이었다 정말 유용합니다. 건배.