none
Need help with architecture for customized program RRS feed

  • Question

  • Hi to all,

    I have a program with a common core but needs small form-level as well as code and database level changes for each different client.

    In the past, I would copy the entire solution and reprogram it for a new client. The real problem with this being, that if I made any updates to the program, I would have to go back and program those changes into every other client's solution, thus adding hours of needless work.

    Should all of my clients be getting the same solution, with different plugins for each? Or should they each have their own solution, all of which reference a set of core classes? Should the code/database level changes lie in the solution's configuration file? I feel like I am missing a key bit of knowledge in the realm of architecture for this type of program.

    Any help would be greatly appreciated.

    Thanks in advance!
    -Bassil
    Thursday, July 31, 2008 4:27 PM

All replies

  • Hi,

     

    Try implementing smart client. I thin kthis will be the best approach.

     

    Thanx & Regards,

    Dev

     

    Friday, August 1, 2008 7:59 PM
  • A smart client architecture is for occasionally connected clients and will have little impact on mantainability over a large client base.

     

    How you meet the requirements of your clients depends on thier requirements.  A common core with plug-ins would work for extra modules.  There's lots of software that have extra modules - HR systems comonly have payroll as a plug-in module for example.

     

    Your code needs to be as flexible as possible and this points to putting as much in configuration settings as possible. 

     

    Whether the work would be worth it depends on how many clients you have.  However, I would certainly wouldn't view an architecture that resulted in mantaining more than one code base as optimal.

     

    You could also look at what things are different in your application.  If there are only a few classes/components that are different you could maintain these and use a configuration file to inform the main component which component or class to use for each client.  This is called dependancy injection.

     

    Hope this helps.

     

    g

     

    Wednesday, September 3, 2008 1:58 PM
  • Bassil;

      I believe the Strategy Pattern fits this problem nicely.

     

    Step 1) Your "common core" becomes the abstract class with as much commonality pulled into it as possible.

    Step 2) Each client inherits this class and contains only specific code for that client.

    Step 3) Pass the concrete classes as a parameter into the "controller" class which directs all the activity.  This controller class takes the Type of the abstact class as it's parameter.

    Step 4) The "Controller" class then issues all commands against the concrete class using the abstract class signature methods.  This allows for the "Controller" class to NEVER change regardless of new client code. 

     

    The best thing about this design is that ALL subsequent client changes needed will NEVER impact any other client code already written.  It's almost like there's a automatic filter built in because the implementation has been separated from the controller code.  Here's a sample of this pattern.

     

     

     

    http://www.dofactory.com/Patterns/PatternStrategy.aspx
    Friday, September 5, 2008 10:48 PM
  • Thanks Javaman, I rushed out my last post and it probably wasn't clear the strategy pattern is what i was alluding to in the last paragraph of my previous post. 

     

    Having a common core module and using the strategy pattern alongside dependancy injection provides a flexible way of managing the different client requirements. 

     

    However, this won't work for a large application or lots of clients.  I this case you would consider building a highly configurable applicaiton.  Multi-tenancy SAAS applciations follow this approach.

    Sunday, September 7, 2008 11:29 AM