I know there are different patterns and approaches to designing service interfaces but I am very much sold on the Request/Response approach that helps to abstract the underlying implementation and will allow me to make changes to the service interface over time without breaking the contract (for the most part). However, inside the service method, once I have the request object, I am actually using a provider model and my CSLA BOs to do the work. Is it better to break-up the request object and use its fields directly as parameters to the method call on my BO? If I change the interface, then I have to make changes in multiple locations.
Let me use an example...
Take the case of user authentication. Let's say is have a LoginService that is used by my client applications. It has a single Login method that accepts a LoginRequest and returns a LoginResponse object. LoginRequest has properties for UserName and Password and LoginResponse has an IsAuthenticated property.
Inside the Login method, I am going to call the SecurityManager.Login() method. This class is used to support a provider model that allows us to change how authentication is actually performed. SecurityManager.Login then calls my SecurityProvider.Login method which, by default, delegates to my User BO's ValidateUser method.
So, you can see that the request actually passes through 4 classes (in the default case) as shown below:
LoginService.Login(...) -> SecurityManager.Login(...) -> SecurityProvider.Login(...) -> User.ValidateUser(...)
If I change the contract, let's say I require an account number or CAPTCHA value or something, then I have to change ALL of these classes! Wouldn't it be better to pass the request as an object between them all just as I do at the service interface?
Help me see the pro's and con's. Thanks!!!
Just to pick on your CAPTCHA example, I'll suggest that having these layers is a good thing.
Your business layer should service the broad use case, which is to authenticate the user. This is true whether the use case is accessed via the web, a service, Silverlight, WPF, a workflow, etc.
Only one of those (web) will have a CAPTCHA concept. So that concept doesn't belong to the business layer, it belongs to the interface layer. It is the kind of thing that should be checked by the interface before the interface invokes the business layer.
So keeping these things separate is beneficial, because you have the flexibility of adding interface-only concepts without messing up the business layer. Conversely, you may sometimes add things to the business layer that don't (necessarily) impact the interface - especially if your interface is an XML service.
A quick follow-up...
Using the Request/Response approach, I am seeing two approaches to creating service interfaces. The seemingly more traditional one has a unique service method for each Request/Response call. This is how I see Rocky doing it in the Project Tracker sample.
The other method, used in particular for Microsoft Dynamics CRM 4, is to have a single service method. In this case, the request object that is instantiated on the service-side has an Execute method that is called by the service to perform the requested action.
I think the first approach is clearer but am drawn to the second because it seems to be much more flexible and, perhaps, even better OO design. To add new functionality is as simply as adding a new Request/Response pair to the interface. And, from an OO perspective, the logic required to carry-out the request is encapsulated within the request object itself. This makes perfect sense.
But, what does this do to discovery and is it really a better way to go? If the service interface doesn't explicity define the type of arguments, how does a client proxy create the necessary classes when a service reference is added?
Copyright (c) Marimer LLC