Visual studio 2010 什么是一个好的解决方案结构，可以方便地根据每个客户定制产品？

我正在寻找一些关于如何允许每个客户轻松定制和扩展核心产品的建议。我知道这可能是个太大的问题。然而，我们真的需要一些想法，如果我们得到了这个错误的设置，它可能会导致我们多年的问题。我没有很多定制和扩展现有产品的经验

我们有一个核心产品，我们通常根据每个客户定制。我们最近用一个MVC3前端在C#4中重写了该产品。我们已经进行了重构，现在有3个项目组成了解决方案：

• 核心域项目（名称空间-projectname.domain.*）-由域模型（供EF使用）、域服务接口等（存储库接口）组成
• 域基础设施项目（namespace-projectname.infrastructure.*）-实现域服务EF上下文、存储库实现、文件上载/下载接口实现等
• MVC3（namespace-projectname.web.*）-由控制器、视图模型、CSS、内容、脚本等组成的项目。它还具有处理项目DI的IOC（Ninject）

此解决方案作为一个独立产品运行良好。我们的问题是在每个客户的基础上扩展和定制产品。我们的客户通常希望能够很快（通常在签订合同后的几天内）获得带有品牌CSS和样式的核心产品版本。然而，70%的客户希望通过定制来改变其工作方式。一些定制很小，例如域模型、视图模型和视图等的附加属性。其他定制更重要，需要全新的域模型和控制器等

有些定制似乎对所有客户机都有用，因此我们希望定期将它们从定制更改为定制并添加到核心

我们目前正在TFS中存储源代码。为了启动一个项目，我们通常手动将源代码复制到一个新的团队项目中。更改名称空间以反映客户端名称，并开始自定义基本部分，然后部署到Azure。这显然会导致代码库完全重复，我确信这不是正确的方法。我认为我们可能应该有一些提供核心特性的东西，并在需要时进行扩展/覆盖。但是我真的不知道该怎么做

因此，我正在寻找关于最佳项目配置的任何建议，以便：

• 代码的快速部署–启动新客户机以便 允许品牌/小改动
• 防止复制和粘贴代码的需要
• 使用尽可能多的DI来保持松散耦合
• 允许在服务器上公开代码 按客户计算
• 能够在单个产品中扩展核心产品 如果我们获得 最新版本的核心和重新部署

---

非常感谢您的帮助/建议。很高兴添加任何人都认为有帮助的更多信息。

我可能无法完全回答这个问题，但这里有一些建议：

无论什么原因，永远不要复制你的代码

不要重命名名称空间以标识给定的客户端版本。为此，请使用分支和持续集成

选择一个分支模型，如下所示：一个名为“Main”的根分支，然后从Main为产品的每个主要版本创建一个分支，然后为每个客户机创建一个分支。当你开发某个东西时，根据你所做的事情，从一开始就瞄准你要开发的分支（客户端分支中会有一个特定于客户端的特性，版本分支中会有一个全局版本，或者如果你想首先对它进行原型化，那么客户端分支中会有一个全局版本，等等）

尽量依靠工作项来跟踪您开发的功能，以了解它是在哪个分支中实现的，从而简化跨分支的合并

为你的开发人员找到合适的分支是最关键的，你不必定义一些“在什么情况下做什么”的硬性规则，但要保持一致

我参与了一个长达10年的大型项目，有超过75个版本，我们通常做的是：

• 下一个主要版本：从Main创建一个新分支，dev-Inside
• 下一次要版本：在当前主要分支中，使用标签标记分支中的每个次要版本
• 一些复杂的函数特性是在请求它的客户机分支中开发的，当我们成功地“取消绑定”它时，就在版本分支中反向集成了
• 在客户端分支中修复错误，然后在需要时在其他分支中报告。（您必须为此使用工作项，否则很容易丢失）

这是我的看法，其他人可能有不同的观点，我非常依赖工作项来跟踪代码，这对代码的交付和报告有很大帮助

编辑

好的，我添加了一些关于分支的想法/反馈：

在软件配置管理（SCM）中，有两个功能可以帮助您进行版本管理：分支和标签。每一个都不比另一个好，也不比另一个差，这取决于你需要什么：

标签用于使用标签标记时间点，以便以后在需要时能够返回到该点

分支用于“复制”代码，以便能够同时处理两个版本

因此，使用分支只取决于您希望能够做什么。如果您必须同时使用一个或多个不同的版本（例如每个客户端一个版本）：除了使用分支之外，没有其他方法可以处理它

要限制分支的数量，您必须决定哪些分支将成为新分支，或者哪些分支将被标记为：特定于客户端的版本、主要版本、次要版本、Service Pack等

使用