더 간단하게 서비스를 포장하는 방법

우리는 3 가지 방법 만 필요한 거대한 인터페이스를 제공하는 타사 서비스에 의존합니다. 또한 인터페이스가 자주 변경됩니다 ...

프로젝트의 클래스에서 인터페이스를 포장하기로 결정하고 필요한 메소드 만 공개하기로 결정했습니다.

그러나 반환 값을 어떻게 처리 해야하는지 잘 모르겠습니다 ... 인터페이스는 유형의 객체를 반환합니다 Storage. 우리는 내부적 StorageModel으로 우리의 내부 표현 인 타입 을 가지고 있습니다 Storage.

당신은 무엇 매퍼에 반환 : Storage나 StorageModel? 우리는 StorageService주입 된 래퍼의 의존성을 얻는 DataService 를 가지고 있습니다 .

현재 기본적으로 다음과 같이하고 있습니다.

public class StorageService 
{
    private readonly IExternalStorageWrapper externalStorageWrapper;

    public StorageService(IExternalStorageWrapper externalStorageWrapper)
    {
        this.externalStorageWrapper = externalStorageWrapper;
    }

    public StorageModel GetStorage(int storageId)
    {
        return this.externalStorageWrapper.GetStorage(storageId).ConvertToStorageModel();
    }
}

public class ExternalStorageWrapper : IExternalStorageWrapper
{
    public Storage GetStorage(int storageId)
    {
        using(var ext = new ExternalStorage())
        {
            return ext.GetStorage(storageId);
        }
    }
}

당신은 무엇을 말할 것입니까 :

• 위와 같이 래퍼가 외부 Storage객체를 StorageService반환하고 내부 가 내부를 반환하는 것이 StorageModel좋습니까?
• 아니면 StorageModel래퍼에 이미 a를 반환 하시겠습니까?

내 의견으로는 래퍼가 외부 라이브러리와 관련된 모든 것을 처리해야합니다. 이는 랩퍼의 공용 인터페이스가 외부 유형의 이름을 지정해서는 안됨을 의미합니다.

외부 유형을 응용 프로그램의 각 유형에 맵핑하는 것은 랩퍼의 의무의 일부입니다. 사소한 작업이 아닌 경우 번역기 개체 주입과 같이 문제를 분해하는 데 사용할 수있는 다양한 도구를 사용할 수 있습니다. 그러나 변환기는 여전히 랩퍼 모듈의 일부 여야하며 응용 프로그램의 다른 부분은 종속되지 않습니다.

이러한 방식으로 나머지 응용 프로그램은 라이브러리의 변경뿐만 아니라 다른 라이브러리로 대체 할 수도 있습니다.

프로젝트의 클래스에서 인터페이스를 포장하기로 결정하고 필요한 메소드 만 공개하기로 결정했습니다.

괜찮아. 어댑터 라고도합니다 .

어댑터 패턴을 선택 하므로 여기서 목표는 하나의 인터페이스 (라이브러리 모델)를 다른 인터페이스 (도메인 모델)로 변환 하는 것 입니다. 따라서 전자의 항목이 도메인 모델에 도달 하면 어댑터가 목적에 실패합니다 .

이전 인수에 따르면 어댑터는를 반환해야합니다 StorageModel.

궁극적으로 도메인 Storage은 낯선 언어 인 특정 언어를 "말합니다" .

그러나 반환 값을 어떻게 처리 해야하는지 잘 모르겠습니다 ...

여기서 핵심 은 라이브러리를 랩 / 적응 하는 이유 를 아는 것 입니다 .

어댑터, 데코레이터, 외관 패턴은 유사 할 수 있지만 상당히 다릅니다. 그들이 해결하는 문제와 다릅니다.

즉, 당신은 또한 관심이있을 수 있습니다 :

• 외관 패턴 (숨김 복잡성)

• 데코레이터 패턴 (인터페이스 향상) . 사용시기

• 어댑터 패턴과 프록시 패턴의 차이점 .

• 반부패 계층이란 무엇이며 어떻게 사용되는지 (품질이 낮고 지저분한 코드 숨기기)

라이브러리를 복제하여 효과적으로 랩핑 할 수 없습니다.

감싸 야 할 것은 라이브러리의 사용법이며,이 경우 라이브러리를 객체로 노출시키지 않습니다. 그것들을 복제하려고 시도하지 마십시오.

라이브러리를 사용하되 포함 된 상태로 유지하십시오. 따라서 귀하의 경우 StorageService를 사용하여 저장소를 저장한다고 가정하면 저장소에 포장해야합니다.

MyPocoObjectRepo
    MyPocoObject GetObject(string id);

MyPocoObject는 전적으로 귀하의 데이터 및 비즈니스 로직입니다. Storage 또는 DataReader 또는 기타 중복되지 않음

대답은 그렇지 않은 Storage클래스에서 직접 액세스해야하는지 여부에 달려 있다는 것 StorageModel입니다.

라이브러리를 랩핑하려는 경우 나중에 라이브러리가 변경 한 증거를 변경할 수 있도록 반환 된 객체도 랩핑하는 것이 좋습니다. 그러나 Storage직접 사용해야 할 경우 상황에 따라 돌아와야 할 수도 있습니다 Storage. 프로그램 전반에 걸쳐 일관성을 유지하기를 원한다면 Storage여기에서 사용법 을 강요해야한다고 주장 할 수 있습니다 StorageModel.

인터페이스와 반환 된 객체를 아직 랩핑하지 않은 경우 래핑하는 것이 좋습니다. 다시 말하지만 StorageModel프로그램 전체 에서만 사용 하고 아닌 경우에만 의미가 있습니다 Storage.