最佳解决方案:扩展方法或新类

在我看来，当设计一个框架时，你应该尽可能多地将解决方案特定的方面保留在框架之外，如果可能的话，让调用实体来处理。

现在我不太确定你的框架将如何使用或有多少不同的网站'项目，但与选项(2)去意味着现在每当一个新的网站被添加的框架现在需要去做的工作，以完成这个功能。以自定义方式使用框架的工作应该由网站处理，而不是由框架处理。如果这个框架发展到使用10个甚至100个网站，这将成为维护的绝对噩梦，并且你的框架最终看起来不像一个框架，而更像一个解决方案特定的产品。使用(1)是一个更干净的解决方案。基本上要保持框架的可重用性和解决方案无关性。

如果你正在设计一个框架，它将被许多不同的项目使用，并且被设计为一段时间，我建议你阅读框架设计指南:可重用。net库的惯例，习惯用法和模式(第二版)

一般来说，如果您控制要扩展的类的源，我会通过继承而不是扩展方法来扩展它。扩展方法非常适合为你无法控制的类添加自定义功能，比如。net内置(String, Enum, IEnumerable)和其他第三方对象。然而，它们可能很难组织，而且它们在技术上是静态方法，为了提高启动性能和内存占用，您通常希望将其最小化。

如果使用扩展，你可能会发现自己陷入命名空间和方法解析的麻烦;假设您将扩展方法放入特定于站点的库中。如果一个站点必须做与另一个站点相同的特定于站点的事情，您必须在另一个站点中包含包含扩展方法的站点库(暴露您可能不希望代码知道的其他事情，可能包含对象或扩展的副本)，或者克隆代码(违反DRY)。

在我看来，创建一个基类并为您的站点特定代码使用覆盖是一个更好的设计。虽然它们可以做到这一点，但扩展方法似乎不适合这种类型的操作。

现在，如果你正在寻找一种方法，在不同的网站上使用共享框架获得不同的值，似乎是网络。Config将满足这种需求。每个站点都有自己的Web。配置，您可以填充特定的属性值，您需要在那里，并有一个单一的函数来检索该值吗?

我会选择1，因为它保持了框架的通用性(和可重用性)和特定的功能，如果我是一个维护程序员，我将看到它。

为了共享功能，我将创建一个基包装器类，特定的包装器从它派生。