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

Community
  • 1
Mixxiphoid
  • 641
  • 1
  • 5
  • 15
  • 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
  • Ah, MEF I completely forgot about that, I will talk it through tomorrow. We talked about the interfacing, but we will still end up with a file for each customer that wants something custom, right? – Mixxiphoid Mar 19 '15 at 20:11
  • 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
  • @JeffO if possible. But I still prefer the easiest in terms of maintenance. – Mixxiphoid Mar 19 '15 at 21:14
  • I think you're going to wind up with at least one file per custom customer, yes, unless the customer can produce it himself. It may be an XML file, or it may be an XML file and a DLL. At the end of the day, it shouldn't really matter, assuming that you can make it a drop-in installation. – Robert Harvey Mar 19 '15 at 21:20
  • @RobertHarvey I was really hoping that wouldn't be necessary :(. I will go through the advice tomorrow with my colleague and come back to this. – Mixxiphoid Mar 19 '15 at 21:31
  • You can put the business rules in a database, but someone is going to have to maintain them. – Robert Harvey Mar 19 '15 at 21: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
  • @Dunk I see what I can do, maybe I could create a picture to describe it better. – Mixxiphoid Mar 21 '15 at 13:51
  • @Dunk I created the picture, I hope it is more clear now. – Mixxiphoid Mar 23 '15 at 19:05
  • Thanks for the diagram Mixxiphoid, it helped a lot. It is what I thought you were asking but wasn't sure. Anyways, Robert's answer should put you on the right track. I haven't used MEF but it seems to do what you want only it seems like it could be a bit much for what you need, but on the flip side might look good on the resume. While not exactly the same it is very similar to what the Entity-Component architecture would get you.... – Dunk Mar 24 '15 at 15:15
  • ...I don't see any way around having to keep a separate configuration for each custom client. You could simplify maintenance by only putting the custom operations in the configuration and use defaults otherwise. – Dunk Mar 24 '15 at 15:15
  • @Dunk thanks for your time. We will surely try using MEF and see how it compares to not using MEF, inheritance isn't optional it seems. – Mixxiphoid Mar 24 '15 at 15:46
  • [The strategy pattern?](https://en.m.wikipedia.org/wiki/Strategy_pattern) – RubberDuck Sep 05 '15 at 01:18

1 Answers1

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,

YSharp
  • 888
  • 6
  • 10