Proposals required for multi-client architecture and custom web application

Question

Our product is a web-based course management system. We have more than 10 customers, and in the future we can get more customers. (Asp.net, SQL Server)

Currently, if one of our customers needs additional functionality or custom business logic, we will change the schema and db code to meet the needs.

(we have only one branch code database and one database schema)

So that the changes do not affect each other's route, we use the client flag, which is defined in the web configuration file, so these additional fields and logic logic apply only to a specific client system.

if(ClientId = 'ABC') { //DO ABC Stuff } else { //Normal Route } 

One of our senior colleagues said that in this way a small company like us can save resources to support multiple resources.

But I feel that this strategy makes our code and database even harder to maintain.

Has someone crossed a similar situation? How do you deal with this?

Refresh . If this is not a valid question for SO, can someone move this question to the correct exchange stack site?

Update2 : You're right. Now the code is getting smelly, and I'm sure it will be a nightmare sooner or later. Our company makes a product and saves efforts, and later products for other customers are based on the previous one. I know that the ideal way is to have the @ ej-brennan dev development teams split into two. One team works on the main product and made it very customizable, and team 2 works on customization for a specific client. However, if our company is so small, this is really a dilemma. :(

Answer 1

I was also in your place, and I agree that it is difficult. In my case, I created custom sites for a single product for customers. While each site followed a similar layout and workflow, each of them should have had enough flexibility to have a fully customizable design, customizable rules for delivery and coupons, as well as various trading gateways and configurations.

A few years later, we ended up with something supported. First, we created libraries to host all of our common code, and placed these libraries in a TFS project, simply called Common. Then we created a new TFS project for each site (and not the client, since many clients had several products / sites) and forked the applicable projects in them from Common. Then we created the VS Template project, which contained the site’s skeleton, including the “constructive” views, controllers and their methods of action (remember that each site had the same basic flow). In addition, each site operated on its own database, which was cloned from an unused and mostly empty template database.

With each site running on its own branch and database, changes can be made to the source stream and design that was installed by the template (which should never be merged back) without affecting any other site. To customize business methods, such as delivery calculations, we could subclass the general class and override where necessary. Part of what allowed was the conversion of all our code to use Injection Dependency. In particular, each Controller introduced Services, and each Service introduced Repositories. Merchants processing was also encoded for the interface and introduced. It is also worth mentioning that this allowed us to hard code all the upsell logic for each site (you bought product X, therefore we recommend Y), which was much easier to create and maintain compared to defining complex configuration rules in our old upsell rule engine. I don’t know if you have something like that ...

Sometimes we would like to make changes to the Common Code itself, which was usually caused by a specific need for a particular site. In this case, we will make changes to this branch, combine them with Common, and then combine them with other sites at our convenience (great for “hacking” changes or changes that also required changes to the database). Similarly, for changes to the database, we need to update the template database and then write a little script to update other site databases with the same schema changes (they should be smart and careful anyway).

An additional advantage was that we also created Mock repositories that will be used / implemented in the configuration of the Design assembly, which allows designers to navigate through the application and work on screens without transferring themselves to the workflow. It also allowed them to start work on the site before something was done in the background, which was very important for those anxious customers who needed to "see something."

10+ customers are certainly not a small amount of what you are talking about. There was enough pain for me. At that time, we had more than 30 sites that were supported by three developers and two designers.

Finally, I know that this is beyond the scope of your question and a little arrogant, but, having received a “final” client’s rejection of the design before the designers actually started to implement it (and before the developers did their job), also saved us a lot of expensive improvements. I know that design is not final, but increasing efficiency at the end of the implementation gave customers less time to change their mind about the design they approved.

I hope that at least you will find several approaches to thinking.

Answer 2

I think you need to decide whether you are selling your own software that you adapt for each client, or ready-to-use software, one-time (and possibly customizable through the features you provide).

When you have only a few clients, as of now, you can get away from what you are doing, but I can almost guarantee that if you continue this path, and your client base will increase, and the number of client-individual settings will increase, you there will be a nightmare; I have come across several clients many times, and it always ends in the same way. All this is manageable, until it is, and then it is a royal neck pain that could make your life very difficult.

If you decide that you are a custom company and want to have several versions of software and a database, everything is all right, just make sure that you take the full cost for this - that is, a factor that may be required to maintain several levels of source code and databases, as well as the factors associated with the fact that these updates will require a lot of deployment effort because you will need to test each client’s database.

If you decide that you want to be a “ready-made” type of product, then your best choice is the ability of each client to customize their experience without the need to change the code, that is, the capabilities built into the setting via configuration screens and tables that control how everything works, - but everyone will still use the same base code and database. Much more work in advance, but saves you a boat time in transit.

Answer 3

People who work with systems that need to change or tune have developed patterns to deal with such problems.

You should definitely start by reading a good book on inversion of control. In short, you can create your own systems by defining building blocks (contracts expressed as interfaces) and providing many implementations. There are several advantages to this approach, but speaking only of two: - you can handle the settings by providing different implementations of the same interfaces - you can reconfigure your application statically or dynamically, but both approaches are much cleaner than your "if"

When it comes to the data layer, check out the repository template. This helps organize data access in such a way that you can switch between different providers. It is great for ioc.

And only technical advice - nhibernate supports dynamic properties. You just provide additional columns in the mapping, and nh can support it from the same code base. This way you can target different databases using slightly different db schemas.