Architecture 客户端定制

我们有一个产品，其安装基数约为50，其中超过50%的安装在业务逻辑的代码中进行了自定义，目前这是通过大量的IF和Switch语句完成的

我们目前正在将代码更新为.NET3.5，并希望以更易于管理的方式处理定制。目前我们唯一能想到的方法是要么坚持使用大型IF和Switch语句，要么在每个客户机的源代码控制中使用单独的文件，这似乎也不理想

---

是否有一种可接受的方式来处理跨代码库的大量定制？

这不叫什么？通过添加自定义功能使类从基类扩展。每当我有大量的If或case时，我都会质疑是否应该重构成多个类。

我会尝试将事情安排成文本形式的定制（可能是XML，但我想这不是唯一的选择），并且主应用程序是通用的，并通过解析这些配置文件来获取特定于客户的功能

然后，您可以为每个客户创建一个存储库，其中包含配置文件（以及可能的资源，如徽标和/或自定义脚本），并为主应用程序创建一个存储库

对于给定的客户版本，构建系统会自动收集应用程序和客户的存储库，并构建自定义版本

---

我有这样一个系统的经验，你可以得到相当广泛的定制方式。首先，它使应用程序方面的事情变得稍微复杂一些，因为您需要添加解析功能，但它使各种客户版本的管理变得更简单，并且更不容易出错。

与继承相结合的DI框架可以使您的系统符合打开/关闭原则，这将使它更加模块化，并将解决生命周期和分发问题，例如当您需要分发为特定客户扩展的基本库时

---

例如，您可以在BaseLibrary中进行类传输，然后可以在CustomerX库中进行类LoggingTransfer扩展传输，该库只包含自定义基本功能的代码。

我认为我们需要了解更多有关自定义内容的信息，以正确回答您的问题-这是外观吗？品牌创建不同的客户特定数据（如价目表）？不同的算法（例如再次定价）。。。