Refactor to Design Patterns: applying adapter pattern to 3rd party API

In order to access data for our Accounts database we need to go through a 3rd party API, which is simply another assembly added as a reference to our solution.

Within a service of ours there are several types of calls to the API that look similar to this:

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

After calling customerCollection.Fill(), the API goes out to the database and runs a query with the appropriate filters. The objects returned belong to the API. Within this service there are many calls to the API all with unique filtering requirements.

What I’d like to do is use the Adapter pattern to put these calls behind my own classes and return the objects that I own. Then I can code against my adapters from my service, and let them worry about calling out to the third party API.

The problem is that I don’t know a good way to handle all of the variations of the filters so that I’m not simply recreating the filtering syntax within my adapters.

I could make extension/static methods that turn the API’s filtering system into a fluent syntax, so it could look like this:

customerCollection.Filter(“MasterCustomerId).Equals(masterCustomerId).Filter(SubCustomer开发者_如何学PythonId).Equals(subCustomerId).Fill();

But something about that just seems wrong. I feel that I’m giving too much responsibility to the service to do all of those calls.

I’m working hard on developing my object oriented skills and I would appreciate if anyone could help point me in the right direction on this issue.

I wouldn't try and re-create their API with your objects. It'll create a very tightly-coupled association and is unlikely to bring you much in the way of benefits.

Your adapter should probably provide a more domain-oriented interface e.g.

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
}

(This is pretty much the repository pattern from Domain-Driven design btw).

In other words, you let the adapter worry about what filtering criteria is needed in the 3rd party API and your calling code deals with sensible business/domain-level concepts.