多个客户端在同一方法中都需要一些不同的功能[关闭](Multiple Clients all requiring some different functionality within the sam

多个客户端在同一方法中都需要一些不同的功能[关闭](Multiple Clients all requiring some different functionality within the same method [closed])

关于以下设置的当前情况的最佳方法是什么;

网站的多个实例 - 每个实例都有自己的SQL数据库。 例如customer1.co.uk，customer2.co.uk -

例如，所有都具有相同的代码库，但需要不同的输出或操作，具体取决于客户是谁。

如果我有这样的情景;

[AccessFilter] [HttpGet] public ActionResult Create(){ // Same initial logic. IF Customer A(){ // Do this customers logic } IF Customer B(){ // Do this customers logic } //Same end result or different result. }

即便如此，该客户希望使用此ViewModel显示此View，但我希望有一个不需要太多重复的过程，或者试图为每个客户维护许多不同的文件。 我想尽可能地为每个客户端特定文件保留不同的发布版本文件夹。

What would be the best approach for the current situation regarding the following setup;

Multiple Instances of the Website - Each with its own SQL database. e.g. customer1.co.uk, customer2.co.uk -

Now for instance, all have the same code base but require different outputs or actions depending on who the customer is.

If I had the scenario of;

[AccessFilter] [HttpGet] public ActionResult Create(){ // Same initial logic. IF Customer A(){ // Do this customers logic } IF Customer B(){ // Do this customers logic } //Same end result or different result. }

Even as far as, this customer wants to display this View, with this ViewModel, but I was hoping to have a process that didn't require much duplication or trying to maintain a lot of different files for each customer. I want to try and stay away from having different release build folders for each client specific file if possible.

最满意答案

正如Culme所说，这将取决于您的确切用例。 但是，我会说随着微服务和持续部署的兴起，代码中的这种分支（使用注册表，环境变量，web.config，等等）：

if Customer A(){ // Do this customers logic } if Customer B(){ // Do this customers logic }

不能很好地扩展。 您最终会遇到比您首先解决的问题更多的问题，并且为每个客户部署特定环境是一件痛苦的事。 然后，当你成功部署它们时，你必须记住那里的神奇公式。 如果你有一个团队，他们将如何知道所有步骤？

容易发生的是你搞乱了一个环境，突然之间他们处于一个完全不同的代码分支上，调试这些问题很痛苦。

在您的情况下，在您的版本控制中创建分支（CustomerA，CustomerB）并以不同方式实现该控制器非常容易。 当CustomerA出现并希望向前移动时，它可能也会有所帮助，但CustomerB非常乐意保持原状。

As Culme said, it will depend on your exact use case. However, I will say that with the rise of microservices and continuous deployment, this sort of branching in your code (using registry, environment variables, web.config, whatever):

if Customer A(){ // Do this customers logic } if Customer B(){ // Do this customers logic }

does not scale well. You tend to end up with more issues than you solved in the first place and it's a pain to deploy specific environments for each customer. Then, when you do deploy them successfully, you have to remember the magical formula for what goes where. And if you have a team, how will they know all the steps?

What easily happens is that you mess up an environment and all of a sudden they're on a completely different branch of code, and debugging those issues is a pain.

In your case, it's pretty easy to just make branches (CustomerA, CustomerB) in your version control and implement that one controller differently. It will probably help too when CustomerA comes along and wants to migrate forward but CustomerB is perfectly happy staying where they are.