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

使用提供者模式创建一组相关的提供者。现在由于新的要求，我想提高我的提供商。供应商是为一些与我们的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）到解决方案。

感谢， DND

来源

2011-09-16 DotNetDude

多个抽象类并不一定是个坏主意，但要考虑的事情可能是继承范例的构成。 http://en.wikipedia.org/wiki/Composition_over_inheritance – Jeff

如果将来需要非XML网页提供程序，如JSON，会怎么样？在这种情况下，在XMLBaseProvider中声明的一些xml特定的属性和方法会变得多余。我会这样做：WebPageBaseProvider作为ProviderBase的抽象子类，然后将XmlWebPageBaseProvider作为子类WebPageBaseProvider。 – mishau

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

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

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

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

来源

2011-12-30 19:03:59 ahoffer

我可以看到在我的基础提供者中使用策略模式的可能性。当意识到这种模式会让我适应供应商的变化时，真的很兴奋。谢谢 – DotNetDude

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

回答

相关问题