0

I have a standard application and in this case, it is an Accounting ASP Net MVC application. Now, I have a new client that has their own specific requirements like other fields and some custom behavior that doesn’t make sense to be included in the standard application.

The most straightforward thing that I could do is to literally copy paste the whole solution and build on top of the standard solution. However, this would mean that if I fix a bug on the standard application, I would also do it on the other solution. Same goes to a new feature implemented in the standard accounting. I would have to do it in both solution and that would be a nightmare to maintain.

Now I’m thinking what would be the best thing to do here. Just to clarify, if possible, I would also like to access the controllers and view of the standard application and sort of inherit it probably to make some client specific change.

Lawrence
  • 135

2 Answers2

2

Your question is very broad, so expect only to get a broad answer.

The general strategy for solving these kinds of problems is to make the requirements customizable. This can be done by introducing run time or compile time switches, configuration files, special code which is only used for a specific customer, "plugins", and so on.

From what you wrote, in your case, a compile time switch would probably be enough to allow two different builds:

  • one build configuration produces the "standard" application

  • another build configuration produces the customized application

Inside your code, there are several ways of using such a switch. For example, a simple #ifdef CUSTOMER_XYZ might be enough for some simple cases. To avoid cluttering of your code with such statements all over the place, there are several techniques available like the strategy pattern, or grouping features together, having switches for each individual customized feature group and then making the above switch only decide about the activation of the groups.

Often, though a compile time switch may be possible, a runtime switch has still advantages, since it reduces build times and makes testing those different configurations easier. But to give you useful advice of what is the right solution for your problem, one needs to know your system and your requirements in detail (which we don't).

As a final note: often people try to abuse branches in their SCM for customization - that has proven itself to be a horrible approach. You find a lot of older questions about this idea on this site, like this one (note I would not recommend to listen to the accepted answer, but to the highest voted answer).

Doc Brown
  • 218,378
0

Maybe you could use a plugin architecture.

Suppose client X has specific requirements regarding component C of the standard product. You have to replace component C by component C', which is a modified version of C. Then you could do this:

  1. Try to separate component C from the kernel of the standard product, such that the kernel only communicates with C through a well defined interface.
  2. Create component C' and let it implement the same interface as component C.
  3. Create a configuration file, which specifies which variant of component C to use. The config file for the standard product refers to component C, while client X has a config file referring to component C'.
  4. Let the kernel read this configuration file and call the right component.

Do this for all components for which the client has specific requirements.

www.admiraalit.nl
  • 1,103