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
Userobject with a nested
Membershipobject, which, in turn, has a nested
- 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
IMembershipServicemethods 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?