What is a good solution structure to allow easy customisation of a product on a per client basis in Entity Framework Architecture? RRS feed

  • Question

  • User1081236289 posted

    I am looking for some advice on how to allow easy customisation, extension of a core product on a per client basis.

    We have a core product that we usually bes poke on a per client basis. We have recently written the the product in C# 4 with an MVC4 frontend. We have refactored and now have 3 projects that compose the solution.

    We have used the Entity Framework DB first architecture.

    Here we are deploying our web product as One Code base for all client and different DB for Each client. (Which means only one code base and it refers multiple db for each client.)

    Some client required additional fields so that we will add it in our code and deployed. in this case we have to add the additional fields in all other clients, we are having(300-600 client) if we add one field then we have to run that scripts in 600DB's it is very hectic.

    Since we are using entity framework if we connect other DB then it required the addional fields.

    if we add additional fields in db than that particular DB only have these fields, the program should take care of the other DB's even that field is not present in Database.

    How To achive this? please advise.



    Wednesday, October 16, 2013 11:52 PM

All replies

  • User398825048 posted

    As also in your previous post, i guess best way to keep a master list of everything in your database and have relation among them per client base. So that your particular application picks only those fields which are applicable to that client.. you have to do it at both db and code level , i guess.

    Thursday, October 17, 2013 2:25 AM
  • User-434868552 posted

    @ Mayil_Gilli                  TIMTOWTDI  =.  there is more than one way to do it

    You say you have three projects in your solution; FWIW, that does not seem relevant.

    is your solution a desktop application?

    if it is a web application, are you hosting all of your customers on ONE server?

    TIMTOWTDI  =.  there is more than one way to do it

    it seems to me that you want only fields COMMON to all clients in your core database.

    fields unique to a single client could be in an extra table for that client;
    one core database that also has 600 custom tables may be better
    than 600 different databases.

    your code could look something like this pseudo-code:

    switch (client_id)
         case 10001:  processTable10001(); break;
         case 10002:  processTable10002(); break;
         case 10003:  processTable10003(); break;
         default:   ~~~~~ process invalid client ~~~~~ ;  break;

    if you can have a single database as suggested above, or some similar concept,
    you will minimize your maintenance nightmare that will come from having
    600 separate databases.

    there are likely many more elegant solutions, however, you need to find a solution
    that minimizes complexity imho.


    P.S.:  if you can disclose more information about the nature of your application,
            your peers here at forums.asp.net might be able to suggest better alternatives.

    Thursday, October 17, 2013 4:45 AM
  • User-488622176 posted

    Can you provide us a list with what you want to customize on a client base? This will allow us to focus. In the worst case, the answer to this could take 255pages :-)

    Thursday, October 17, 2013 9:40 AM
  • User1081236289 posted

    Hi llleris,

    Good Question. Our customization as follows.

    Scenario1: Some clients required new fields to capture some different information

    Say in a years time 'Mario Pizza' has a need for a field: "number of guests per table". One way is to have a plugin architecture to faciliate this

    Scenario: Some clients required new functionality in the exsisting system.



    Friday, October 18, 2013 12:11 PM
  • User-488622176 posted

    Ok, so you want to extend on a customer base. Meaning : you add things to a base version that is shared for all customers. This is the most "easy" thing to do (and also the best approach : you cannot maintain 100 versions of 1 app, but you can maintain 100 extensions)

    In your case you'll need to provide extension points on your software that can be configured per instance (ex: using a config file). The extensions will be in separate assemblies. The config file determines what extensions you have. The extension points read the config file. Example:

    • A menu extension point : logic that handles dynamic menu creation, and reads the config file for specific entries (extension)
    • The config file contains per menu item the controller & assembly that must be loaded to invoke the functionality
    • You integrate this in your asp.net mvc controller to allow it being called

    In order to allow data model changes, you'll need to be able to modify the MVC views also. The easiest approach is as shown here : http://stackoverflow.com/questions/16808613/handling-custom-fields-using-the-entity-framework. You provide the option for custom fields in you model. You can also create a generic MVC control for handling these fields. By this everything is configuration in your application not requiring code changes.  

    Monday, October 21, 2013 8:15 AM