WCF Business logic handling

Question

I have a WCF service that supports about 10 contracts, we have been supporting a client with all the business rules specific to this client now we have another client who will be using the exact same contracts (so we cannot change that) they will be calling the service exactly the same way the previous client called now the only way we can differentiate between the two clients is by one of the input parameters. Based on this input parameter we have to use a slightly different business logic – the logic for both the Client will be same 50% of the time the remainder will have different logic (across Business / DAL layers) . I don’t want to use if else statement in each of contract implementation to differentiate and reroute the logic also what if another client comes in. Is there a clean way of handling a situation like this. I am using framework 3.5. Like I said I cannot change any of the contracts (service / data contract ) or the current service calling infrastructure for the new client. Thanks

Answer 1

Can you possibly host the services twice and have the clients connect to the right one? Apart from that, you have to use some kind of if-else, I guess.

Answer 2

I can't say whether this is applicable to you, but we have solved a similar problem along this path:

• We add a Header information to the message that states in which context some logic is called.
• This information ends up in a RequestContext class.
• We delegate responsibility of instantiating the implementation of the contract to a DI Container (in our case StructureMap)
• We have defined a strategy how certain components are to be provided by the container:
  • There is a default for a component of some kind.
  • Attributes can be placed on specializations that denote for which type of request context this specialization should be used.
• This is registered into the container through available mechanisms
• We make a call to the Container by stating ObjectFactory.With(requestcontext).getInstance<CONTRACT>()
• Dependencies of the service implementations are now resolved in a way that the described process is applied. That is, specializations are provided based ultimately on a request information placed in the header.

This is an example how this may be solvable.