architecture - 客户定制

Question

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

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

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

例如，您可以在 BaseLibrary 中有一个类 Transfer，然后您可以在 CustomerX 库中有一个类 LoggingTransfer 扩展 Transfer，该库仅包含自定义基本功能的代码。