Multiple Clients all requiring some different functionality within the same method [closed]

Question

What would be the best approach for the current situation regarding the following setup;

Multiple Instances of the Website - Each with its own SQL database. e.g. customer1.co.uk, customer2.co.uk -

Now for instance, all have the same code base but require different outputs or actions depending on who the customer is.

If I had the scenario of;

[AccessFilter]
[HttpGet]
public ActionResult Create(){ 
    // Same initial logic.

    IF Customer A(){
        // Do this customers logic
      }
    IF Customer B(){
        // Do this customers logic
      }
   //Same end result or different result.
}

Even as far as, this customer wants to display this View, with this ViewModel, but I was hoping to have a process that didn't require much duplication or trying to maintain a lot of different files for each customer. I want to try and stay away from having different release build folders for each client specific file if possible.

Answer 1

As Culme said, it will depend on your exact use case. However, I will say that with the rise of microservices and continuous deployment, this sort of branching in your code (using registry, environment variables, web.config, whatever):

if Customer A(){
        // Do this customers logic
}
if Customer B(){
        // Do this customers logic
}

does not scale well. You tend to end up with more issues than you solved in the first place and it's a pain to deploy specific environments for each customer. Then, when you do deploy them successfully, you have to remember the magical formula for what goes where. And if you have a team, how will they know all the steps?

What easily happens is that you mess up an environment and all of a sudden they're on a completely different branch of code, and debugging those issues is a pain.

In your case, it's pretty easy to just make branches (CustomerA, CustomerB) in your version control and implement that one controller differently. It will probably help too when CustomerA comes along and wants to migrate forward but CustomerB is perfectly happy staying where they are.

Answer 2

I'd say there is no single best approach, it all depends, and regardless of what you choose it will have it's benefits and drawbacks.

I the requirements are hugely different for each client, separate applications could be a good solution, but if only minor parts of the logic is different you'll probably be better off with a single application.

If you choose to make one application, it is probably a good idea to try to separate the client specific code by putting it in it's own namespace or class, so you don't clutter your "core" code with tons of if/case/switch code.