Code structure for multiple applications with a common core

Question

I want to create two applications that will have a lot of common functionality. Basically, one system is a more advanced version of the other system. Let's call them Simple and Advanced. The Advanced system will add to, extend, alter and sometimes replace the functionality of the Simple system. For instance, the Advanced system will add new classes, add properties and methods to existing Simple classes, change the behavior of classes, etc.

Initially I was thinking that the Advanced classes simply inherited from the Simple classes but I can see the functionality diverging quite significantly as development progresses, even while maintaining a core base functionality. For instance, the Simple system might have a Project class with a Sponsor property whereas the Advanced system has a list of Project.Sponsors. It seems poor practice to inherit from a class and then hide, alter or throw away significant parts of its features.

An alternative is just to run two separate code bases and copy the common code between them but that seems inefficient, archaic and fraught with peril. Surely we have moved beyond the days of "copy-and-paste inheritance".

Another way to structure it would be to use partial classes and have three projects: Core which has the common functionality, Simple which extends the Core partial classes for the simple system, and Advanced which also extends the Core partial classes for the advanced system. Plus having three test projects as well for each system. This seems like a cleaner approach.

What would be the best way to structure the solution/projects/code to create two versions of a similar system? Let's say I later want to create a third system called Extreme, largely based on the Advanced system. Do I then create an AdvancedCore project which both Advanced and Extreme extend using partial classes? Is there a better way to do this?

If it matters, this is likely to be a C#/MVC system but I'd be happy to do this in any language/framework that is suitable.

Answer 1

The best approach here is to have the Model of the MVC triad in a separate, common project. This Model should provide all the model features that are needed by the various versions. But the model should not implement the restrictions that differentiate the Simple version from the Advanced version. To take your example, if the Advanced version supports multiple Sponsors for a project, and the Simple version only one Sponsor, then the model should cater for a list of Sponsors, even though this is less efficient for the Simple version.

For each version, you create a separate project containing the View and Controller parts of the MVC triad. This is also where you put the version-specific restrictions in, like having only a single Sponsor for a Project in the Simple version.

• Azrael Seraphin: I don't think this works as the model is where the functionality will differ. For instance, let's say the Simple system uses cash accounting and the Advanced system uses accrual accounting - this is a fundamental difference in the behavior at the model level and having a slightly different controller isn't going to help.
• Bart van Ingen Schenau: @AzraelSeraphin: Depending on the number of such fundamental differences, either the model could support both options (leaving one unused in the different versions), or there isn't enough common functionality to consider sharing it.
• Azrael Seraphin: So your suggestion would be to run two seperate code bases and copy code between them as needed even though more than half the functionality will be shared?
• Bart van Ingen Schenau: @AzraelSeraphin: If more than half the functionality is shared, I recommend using a single codebase for the model that supports the union of the functionalities of the different versions.