使用提供者模式创建了一组相关的提供者。由于给我的新要求，现在想加强我的供应商。这些提供程序是为一群与我们的网络服务集成的客户创建的。现在，一些相同的客户希望使用网页与我们集成。通过我们的网页，前端逻辑当然会有所不同，但一半的提供者逻辑是相同的。所以我正在考虑在特定的客户提供者中添加另一个抽象类来处理与提供者的网页集成。这是使用可能的增强功能的代码 ex:
//Same Customer provider dll
//Methods defined for handling web service integration
public abstract class XMLBaseProvider : ProviderBase
//Methods defined for handling web page integration logic
public abstract class XMLWebPageBaseProvider : XMLBaseProvider
现在，在 app.config 中，我定义了另一个指向 XMLWebPageBaseProvider 的提供程序部分以及一个新的提供程序名称。这行得通，但想知道我是否滥用了以这种方式编码的提供者模式？这样做有什么我应该担心的问题或陷阱吗？这里有人像我上面描述的那样实现了这种提供者模式吗？
另请注意，我们可能会有更多客户使用网页集成与我们集成。我只是讨厌不得不不断地向解决方案中添加越来越多的提供程序 (dll)。
谢谢， 免打扰
最佳答案
我觉得你的想法很好。对于您所描述的内容，您的设计可以正常工作。不过，正如其中一位评论员指出的那样，这些要求可能会扩展到 JSON。根据我的经验，对不同格式的需求总是会随着时间的推移而增长。当这种情况发生时，继承变得非常脆弱。类层次结构将增长到越来越多的抽象类层次。最终将难以管理。
评论员建议使用组合，我同意。从长远来看，策略或访问者模式可能会更好地为您服务。
如果应用程序对业务至关重要并且业务正在增长，请考虑更进一步。将尽可能多的提供程序逻辑从代码中移出并移到配置文件或配置数据库中。从长远来看，这将是一个巨大的胜利，因为它最大限度地减少了在需求增长时必须更改的代码量。更改代码有产生错误的风险，需要进行新的构建和部署等。更改一些数据要容易得多，风险也小得多。
这种策略通常被称为数据驱动编程。看看this question .
关于c# - 使用提供者模式——多个抽象类，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7448784/