Refactor to Design Patterns : 타사 API에 어댑터 패턴 적용

Question

Google 계정 데이터베이스의 데이터에 액세스하려면 솔루션에 대한 참조로 추가 된 다른 어셈블리 인 타사 API를 사용해야합니다. 우리의 서비스이 비슷한 보이는 API 호출의 여러 종류가 있습니다 내

는 :

ICustomers customerCollection =GetCollection(OrgId,OrgUnit,CustomerInfo, "Customers"); 
     { 
      customerCollection.Filter.Add("MasterCustomerId", QueryOperatorEnum.Equals, masterCustomerID); 
      customerCollection.Filter.Add("SubCustomerId", QueryOperatorEnum.Equals,subCustomerID); 
     } 
     customerCollection.Fill(); 

customerCollection.Fill()를 호출 한 후는, API는 데이터베이스에 외출하고 적절한 필터를 사용하여 쿼리를 실행합니다 . 리턴 된 오브젝트는 API에 속합니다. 이 서비스에는 고유 한 필터링 요구 사항이있는 API에 대한 호출이 많이 있습니다.

내가하고 싶은 것은 어댑터 패턴을 사용하여이 클래스를 자신의 클래스 뒤에두고 자신이 소유 한 객체를 반환하는 것입니다. 그러면 내 서비스에서 내 어댑터에 대해 코드를 작성할 수 있으며 타사 API를 호출하는 것에 대해 걱정할 수 있습니다.

문제는 필자가 어댑터의 필터링 구문을 다시 작성하지 않고 모든 필터 변형을 처리하는 좋은 방법을 모른다는 것입니다.

나는 유창 구문에 API의 필터링 시스템의 전원을 켤 확장/정적 메소드를 만들 수있는, 그래서 같이 수 :

customerCollection.Filter(“MasterCustomerId).Equals(masterCustomerId).Filter(SubCustomerId).Equals(subCustomerId).Fill(); 

을하지만 그것에 대해 뭔가는 잘못된 것 같다. 나는 모든 전화를 할 수있는 서비스에 너무 많은 책임을 부여한다고 생각합니다.

저는 객체 지향 기술을 개발하기 위해 열심히 노력하고 있습니다. 누군가이 문제에 대해 올바른 방향으로 나를 도울 수 있다면 감사하겠습니다.

Answer 1

개체로 API를 다시 만들지 않으려 고합니다. 그것은 매우 긴밀하게 연계 된 연상을 만들어 낼 것이며 혜택을 많이 얻지 못할 것입니다.

어댑터는 아마도 도메인 지향 인터페이스를 제공해야합니다.

public IList<MyCustomerObjects> GetCustomers() 
{ 
    //Call out to the third party API with the appropriate filters 

    //foreach object in 3rd party collection, wrap in adapter class and add to list 

    //return list of your objects 
} 

(이는 도메인 기반 디자인 btw의 저장소 패턴과 거의 같습니다.)

즉, 어댑터에서 제 3 자 API에 필요한 필터링 기준이 무엇인지에 대해 걱정하게하고 호출 코드는 합리적인 비즈니스/도메인 수준 개념을 처리합니다.