4

We got a project where we have to process certain requests which the customer sends. The request is either in a generic format or in a customer format (all xml) which is then converted to the generic version.

Then some objects are created which are stored in the clients database to be read at a later moment.

Then the moment comes we have to read this information and do stuff with it. 100% of this will be done in a generic handler class, but each customer will have parts that it would like to have differently handled. This can be about any of the fields we process.

Me and my colleague were arguing about the best way to implement this without getting 100+ classes that inherit from the generic version and override those methods that process a certain field the customer wants different. Soon the discussion drifted off to the use of reflection (we program in C#) and dirty configuration files.

I tried searching Google and this site, but couldn't find anything closely related, perhaps I don't know the terms to search for. I already tried these links, but do not cover my case or are actually about something else.

A bit more information about the process:
The custom parts involve certain codes that only that customer uses or certain business rules that only apply to one customer. On top of that it is possible that certain cases should be completely ignored for one or two customers where the base class does not.

The question is:
What is the best way to handle customer specific logic within a generic process?

If this is a duplicate, I'd really like to know how you found it!
If there is more information needed, I'd be happy to supply.

Update: I created this picture in the hope it would give a better understanding of what I want to achieve. As you can see in the picture, each customer has its own set of overrides of the bigger process. Customer specific logic

  • Is it just about providing a way for the customer to put in their custom parts that are only visible to them? – Robert Harvey Mar 19 '15 at 19:56
  • No, it is more like the customer not wanting to use the standard version and telling us to implement it their way for them. The names of the fields will be the same (see the top of my post), even the content can be the same, but they still want it to be handled their way. – Mixxiphoid Mar 19 '15 at 19:57
  • There are a number of ways to extend existing functionality, some of which are already familiar to you. The most common way is to write a new implementation against an interface. You can extend this implementation to be loadable at runtime. You should also consider looking at the Managed Extensibility Framework. – Robert Harvey Mar 19 '15 at 20:00
  • 1
    Are you trying to avoid compiling differently for each client? Could you rely on different xslt files that are customized as needed? – JeffO Mar 19 '15 at 20:55
  • 1
    What this question is asking is as clear as mud. Can you possibly rewrite to be more concise, clear or specific. Preferably all three. Since I only have a really vague guess at what you are asking, I could be off in the weeds. However, I am wondering if an Entity-Component type architecture would fit your needs. – Dunk Mar 20 '15 at 19:14
3

There are several options you can consider to tackle this problem at the design level.

Pattern-wise, you might want to get yourself a refresher about, including, albeit not limited to:

The abstract factory design pattern

http://www.dofactory.com/net/abstract-factory-design-pattern

which could maybe used in combination with:

The strategy design pattern

http://www.dofactory.com/net/strategy-design-pattern

If statefulness of your implementation is likely to come into play, the state design pattern, in combination with either or both the above, may also help (also presented dofactory).

'Hope this helps,

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.