Question

I have a client application that should be able to handle the following:

1) Request sql statments that are to to be executed against the client.
2) Request Service Packs or Hoxfixes that will be executed against to the client.
3) There may be more types of tasks the client could do in the future.

Executing each of these task types produces some kind of Result. For the sql statements, the results is a dataset, that I’m serializing back to the server via WCF method call, so the data can be saved. Although I haven’t gotten to this point of development yet, I can assume that the result of a service pack execution may be an indication of the execution status. i.e. Sucess, Fail, ErrorMessage. This infomation would also need to be transfered over the wire via WCF so that it can get recorded. So far there are two result possibilities. This varying return information could be put into a class like “ExecutionResults” but the actions taken to save each type of ExecutionResult will be different.

The question is should I go through the trouble of trying to setup a shared (abstract type) that both client and server know about and then convert this type to the correct concrete type on the server? Or should I just create a separate service method for each of these different scenarios?

Answer 1

If you use shared base type with sub types you still have to provide sub types to both client and server and you have to use KnownTypeAttribute on the base type. This is one way to go.

I would choose the second approach with different operation for each activity. The reason is that those activities doesn’t have any shared context. Each is absolutly different request so I guess better design is to use separate methods. You don’t know what task should be handled in the future so this design will be much better extendable and consistent. Also adding operations to contract without affecting existing operations is better for versioning.