使用提供者模式 - 多个抽象类

Question

使用提供者模式创建了一组相关的提供者。由于给我的新要求，现在想增强我的提供者。这些提供程序是为与我们的 Web 服务集成的一群客户创建的。现在，一些相同的客户希望使用网页与我们集成。浏览我们的网页，前端逻辑当然会有所不同，但提供者逻辑的一半是相同的。所以我正在考虑在特定的客户提供商中添加另一个抽象类来处理与提供商的网页集成。这是一个使用可能增强功能的代码：

//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）。

谢谢， 免打扰

Answer 1

我认为你的想法很好。根据您的描述，您的设计将正常工作。不过，正如其中一位评论员所指出的，这些要求可能会扩展到 JSON。根据我的经验，对不同格式的需求总是随着时间的推移而增长。当这种情况发生时，继承变得非常脆弱。类层次结构将增长到越来越多的抽象类级别。到最后会很难管理。

评论员建议使用构图，我同意。从长远来看，策略或访问者模式可能会更好地为您服务。

如果应用程序对业务至关重要并且业务正在增长，请考虑更进一步。将尽可能多的提供程序逻辑从代码中移出并放入配置文件或配置数据库中。从长远来看，这将是一个巨大的胜利，因为它最大限度地减少了需求增长时必须更改的代码量。更改代码可能会产生错误，要求进行新的构建和部署等。更改某些数据要容易得多，风险也较小。

这种策略通常被称为数据驱动编程。看看this question。