2012-08-29

Tightly coupling generic types

Update: Instead of decorating responses with IResponseFor<T> I now instead decorate the command/query with IExpectResponse<T> - Each command/query should only have one response type, and this way it makes it possible to specify the return type should be something simple like a GUID.

My server application works purely on a request/response pattern, like so
var query = new GetCustomerQuery(customerUniqueID); var response = AppServer.Execute<GetCustomerQuery, GetCustomerQueryResponse>(query);


What I wanted to avoid though was the possibility that the user (me writing the client app) would do something silly like the following code and use the wrong pair combination


var query = new GetCustomerQuery(customerUniqueID); var response = AppServer.Execute<GetCustomerQuery, GetEmployeeQueryResponse>(query);


Up until now I had the server interface defined like this, so that I can at least ensure the generic parameters are a Query and Response…


TResponse Execute<TRequest, TResponse>(TRequest request) where TRequest : Request where TResponse : Response;


But a very simple addition ensured that the response type specified is the right type for the request.


TResponse Execute<TRequest, TResponse>(TResponse response) where TRequest : Request where TResponse : Response, IResponseFor<TRequest>;


Then when I create my GetCustomerQueryResponse class I merely need to declare it like so


public class GetCustomerQueryResponse : Response, IResponseFor<GetCustomerQuery> { //etc }


Now the client code above won’t compile because GetEmployeeQueryResponse does not implement IResponseFor<GetCustomerQuery>.

No comments: