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; 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. 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?

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?