客户端定制化

Question

3

我们有一个安装基数约为50的产品，其中超过50％的安装都具有业务逻辑代码的定制，目前是通过大量的IF和Switch语句完成的。

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

是否有一种被接受的方法来处理跨代码库的大量定制内容呢？

- J16saw

1

我认为我们需要更多了解定制的内容，才能恰当地回答您——这是外观吗？品牌？不同的客户特定数据（例如价格表）？不同的算法（例如再次定价）... - The Archetypal Paul

3个回答

2

我倾向于将定制化以文本形式进行排列（可能是XML，但我猜这不是唯一的选择），并使主应用程序通用，并通过解析这些配置文件来获取客户特定功能。

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

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

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

- Kena

0

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

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

- Dan

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- fallen888 · Accepted Answer

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