在架构所需的多个客户端，可定制的web应用程序的建议 [英] Suggestions needed on an architecture for a multiple clients and customisable web application

问题描述

我们的产品是一个基于网络课程managemant系统。我们有10+的客户，将来我们可能会得到更多的客户。 （Asp.net中，SQL Server）

Our product is a web based course managemant system. We have 10+ clients and in future we may get more clients. (Asp.net,SQL Server)

目前，如果我们的一个客户需要额外的功能或定制的业务逻辑，我们将改变DB模式和code，以满足需求。

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

（我们只有一个分支code群和一个数据库架构）

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

要做出改变不会影响到每个人的路线，我们使用客户端的标志，它在网络配置文件中定义，因此这些额外的领域和BIZ逻辑只适用于一个特定的客户的系统。

To make the change wont affect each others route, we use a client flag, which defined in a web config file, thus those extra fields and biz logic only applied to a particular customer's system.

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

说我们的一位资深同事，这样，小公司像我们这样可以节省支持多个资源的资源。

One of our senior colleagues said, in this way, small company like us can save resources on supporting multiple resources.

但我的感觉是，这种策略使得我们的code和数据库更难维持。

But what I feel is, this strategy makes our code and database even harder to maintain.

任何人有交叉类似的情况？你是如何处理的？

Anyone there crossed similar situation? How do you handle that?

更新：如果这不是一个正确的问题那么，有人可以这个问题转移到一个适当的stackexchange网站

Update:If this is not a right question for SO, can someone move this question to a proper stackexchange site?

UPDATE2 ：
你是对的。在code现在越来越臭，我相当肯定会是一场噩梦迟早的事。我们公司是做产品，节约的功夫，后来产品的其他用户的基础上，previous之一。我知道，理想的方式是单独的@ E-J-布伦南开发团队分为两部分。一个团队工作在核心产品，并使其高度可定制的，和团队定制特定客户端两件作品。但是，如果因为我们的公司是如此之小，实在是一个两难的局面。 （

Update2: you are right. The code is becoming smelly now, and I quite sure will be a nightmare sooner or later. Our company is doing the product and to save the effort, later products for other customers are based on the previous one. I know the ideal way is seperate the @e-j-brennan dev teams into 2 parts. One team works on core product and made it highly customisable, and team two works on customising for a particular client. However if since our company is so small, it is really a dilemma situation. :(

推荐答案

我也一直在你的位置，我同意这是一个艰难的一年。就我而言，我是构建为客户定制的单一产品的网站。虽然每个网站也出现了类似的布局和工作流程，必须有足够的灵活性，每个有一个全定制设计，围绕航运和优惠券定制的规则，不同厂商的网关和配置。

I have also been in your position, and I agree it is a difficult one. In my case, I was building custom single-product sites for clients. While each site followed a similar layout and workflow, there had to be enough flexibility for each to have a wholly custom design, custom rules around shipping and coupons, and different merchant gateways and configurations.

若干年后，我们没有最终的东西维护。首先，我们创建库容纳所有我们共同code，并把这些库到TFS项目简称为常见。然后，我们创建了一个新的TFS项目为每个站点（而不是客户端，许多客户有多个产品/网站）和支适用的项目，它们将共同。接下来，我们创建了一个包含该网站的骨架，其中包括设计 - 少的观点，控制器和他们的行动方式（请记住，每个站点有相同的基本流程）一个VS模板项目。此外，每个站点运行在自己的数据库，这是从其他未使用的且多为空的模板克隆DB

After some years, we did end up with something maintainable. First, we created libraries to house all of our common code and put those libraries into a TFS project simply called Common. Then, we created a new TFS project for each site (not client, as many clients had multiple products/sites) and branched the applicable projects into them from Common. Next, we created a VS Template project that contained a skeleton of the site, including "design-less" views, controllers, and their action methods (remember, each site had the same basic flow). Also, each site ran on its own database, which was cloned from an otherwise unused and mostly empty Template DB.

通过每个站点上自己的分公司和DB运行，修改可以到原来的流程和设计，是由模板（这将永远需要在合并回），而不会影响任何其他网站安装的。对于定制业务的方法，如计算运费，我们可以创建普通类的子类，并覆盖在需要的地方。是什么使这是将所有我们的code使用依赖注入的一部分。具体来说，每个控制器都注射服务，每个服务都注入存储库。商户处理也是coded到一个接口和注射。另外值得一提的是，这使我们能够硬code所有加售逻辑的每个站点（你买的产品X，所以我们建议Y），这是更容易创建和比较，确定在复杂的配置规则维护我们的老追加销售规则引擎。我不知道你有没有这样的事情......

With each site running on its own branch and DB, modifications could be made to the original flow and design that was installed by the template (which would never need to be merged back in) without affecting any other site. For customizing business methods, like shipping calculations, we could create a subclass of the common class and override where needed. Part of what enabled this was converting all our code to use Dependency Injection. Specifically, each Controller had injected Services, and each Service had injected Repositories. Merchant Processing was also coded to an interface and injected. Also worth mentioning is that this allowed us to hard-code all of the upsell logic for each site (you bought product X, so 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 anything like that...

有时我们会想做出改变，以共同code本身，这通常是通过一个特定的需要对特定的网站提示。在这种情况下，我们会想办法让该分支上的变化，它合并公用，然后将其合并到我们的方便的其他网站（伟大的破的变化或变化也需要更改为DB）。同样，对于DB的变化，我们将更新模板数据库，然后写一个小脚本使用相同的架构更改更新其他站点的DB（仍然是聪明和小心的话）。

Sometimes we would want to make a change to the Common code itself, which was usually prompted by a specific need for a specific site. In that case, we'd make the change on that branch, merge it to Common, and then merge it to the other sites at our convenience (great for "breaking" changes or changes that also required a change to the DB). Similarly for DB changes, we would update the Template DB and then write a little script to update the other site DBs with the same schema changes ( still had to be smart and careful about it).

另外一个好处是，我们还创建了设计构建配置，这使设计师跳来跳去的应用和工作在屏幕上逐字没有提交自己对工作流注入将用于模拟库/。它还允许在后端，这是谁需要看到那些着急的客户非常重要之前有任何事情他们开始在现场工作。

An added benefit was that we also created Mock repositories that would be used/injected in a "Design" build configuration, which enabled the designers to jump around the application and work on screens without literally submitting themselves to the workflow. It also allowed them to start working on a site before there was anything done on the back-end, which was very important for those anxious clients who need to "see something".

10+的客户绝对不是一个小数目与你在说什么。三是疼痛足以让我。我们已经运行在同一时间超过30个地点，由三个开​​发人员和两位设计师维护。

10+ clients is definitely not a small number with what you're talking about. Three was pain enough for me. We had over 30 sites running at one time, maintained by three developers and two designers.

最后，我知道这是你的问题的范围和位presumptuous之外，但得到的设计最终客户签收前，设计师居然跑到其实现（和开发者做自己的事情前）也我们节省了很多成本高昂的返工。我知道没有设计完成，但在结束执行效率提高了客户更少的时间来改变对他们批准的设计他们的想法。

Finally, I know it's outside the scope of your question and a bit presumptuous, but getting "final" client sign-off on design before the designers actually went about implementing it (and before devs did their thing) also saved us a lot of costly rework. I know no design is final, but increasing efficiency on the implementation end gave the clients less time to change their minds about the design they approved.

我希望，至少给你一些方法去思考。

I hope that at least gives you some approaches to think about.

这篇关于在架构所需的多个客户端，可定制的web应用程序的建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！