Client Customizations

Question

We have a product with an install base of about 50, over 50% of these installs have customizations in the code for the business logic, and that is currently done by huge IF and Switch statements.

We are currently in the process of updating the code to .NET 3.5 and would like to handle the customizations in a more managable way. The only ways we can think of at the moment are to either stick with the large IF and Switch statements or have seperate files within Source Code Control for each client, which again doesn't seem to be ideal.

Is there an accepted way of handling large numbers of customizations across a codebase?

Answer 1

I would be tempted to arrange things so that customization is in text-form (possibly XML, but I guess that's not the only option), and the main application is generic, and gets the customer specific features by parsing those configuration files.

You could then have a repository for each customer, containing configuration files (and possibly resources, like logos, and/or custom scripts), and a repository for the main application.

For a given customer version, your build system then automatically gathers the application and the customer's repository, and builds the custom version.

I have experience with such a system, and you can get quite extensive customization that way. It makes things a little bit more complex on the application side at first, because you need to add parsing functionality, but it makes management of various customer versions a lot simpler, and somewhat less error prone.

Answer 2

Isn't this called inheritance? Having classes extend from base classes by adding custom functionality. Whenever I have a large number of If's or cases, I question whether I should refactor into multiple classes.

Answer 3

A DI framework in combination with inheritance could keep your system in accord to Open/Closed principle, would make it more modular, and would resolve lifecycle and distribution problem, like when you need to distribute a base library that was extended for a specific customer.

For example, you can have a class Transfer in BaseLibrary and then you can have a class LoggingTransfer extends Transfer in CustomerX library that contains only the code that customizes the base functionality.