Designing models for a generic service layer

Question

We are building a web interface to a tiered membership system, which will interface with a third-party CRM web service for the creation and management of accounts. The web service, unfortunately, is not yet built; however, we need to begin work.

I have created an interface, IMembershipService, in which I am beginning to define "best-guess" prototypes, so we can begin building our User Controls. Most of these methods will return some data bundled in a Model object, e.g.:

ContactModel GetContact (string userId);

When the web service methods become available, I will create a concrete implementation of IMembershipService that will wire up the controls to the web service.

The problem I have is that I don't yet know whether the web service will consist of:

• calls returning complex objects; e.g. a User object with a nested Membership object, which, in turn, has a nested PaymentMethod object
• simple calls for specific pieces of information; e.g. String GetUserMembershipType (string userId);

This is causing me to have trouble specifying the structure of the models and interface, which is causing problems for the developers beginning work on the User Controls:

• If the service returns complex objects, I don't want my IMembershipService methods to be too simple, forcing me to use multiple web service calls where it is not necessary.
• If the service consists of simple calls, I don't want to have a load of complex models defined that I then can't implement, thereby having to do a load of refactoring.

In theory, creating IMembershipService should allow me to abstract away from the actual nature of the web service, but the fact that each call to a method in IMembershipService will, ultimately, result in a web service call, thereby adding overhead, is making this difficult to spec.

How can I design my models and IMembershipService in order to minimize the amount of refactoring I have to do when the nature of the web service becomes less elusive?

Answer 1

Decide on the most convenient interface for your application, and define an interface according to that. What information will you need, and in what discrete units? Define models according to those units.

After all is said and done, that's the information you need. Let the implementation later be an adapter to the webservice. It won't matter if it needs to do multiple callstothe webservice or not - that's just an implementation detail.