所以我会尝试在这个上扮演魔鬼的拥护者......
假设有一个框架可以为2个或3个不同的网站提供服务。 1框架的基本功能是处理对某个DB的所有调用。在进行数据库调用时，网站会调用Framework DataSource对象并返回一个通用的Framework数据对象。
现在，为了让网站检索特定于其需求的属性/方法，我们有2个解决方案选项。
创建一个新类，扩展或包装通用数据对象， 暴露更多域友好的属性＆amp;保留任何域名 这个新类内部的特定功能。
不是创建新类，而是在Framework中创建扩展方法来为这些网站提供服务。一切都是 包含在框架内，可以在网站之间共享 如果需要1天。
这里只是澄清一下例子： 属性：
方法
那么你会选择什么样的解决方案？ 1还是2？
干杯。
答案 0 :(得分：1)
通常，如果您控制要扩展的类的源代码，我会通过继承而不是扩展方法来扩展它。扩展方法非常适合向您无法控制的类添加自定义功能，例如.NET内置函数（String，Enum，IEnumerable）和其他第三方对象。但是，它们可能难以组织，并且它们在技术上是静态方法，您通常希望最小化这些方法以启动性能和内存占用。
通过使用扩展，您可能还会发现自己在命名空间和方法解决方面遇到麻烦;假设您将扩展方法放入特定于站点的库中。如果一个站点必须执行与另一个站点相同的站点特定事物，则必须在另一个站点中包含一个包含扩展方法的站点库（暴露您可能不希望代码知道的其他内容，可能包含对象的重复项）或者扩展），或克隆代码（违反DRY）。
答案 1 :(得分：1)
在我看来，在设计框架时，您希望在框架外保留尽可能多的解决方案特定方面，并让调用实体在可能的情况下处理。
现在我不太确定您的框架将如何使用或者有多少不同的网站\项目，但选项（2）意味着现在每当添加新网站时，框架现在需要按顺序工作完成此功能。以自定义方式使用框架的工作应该由网站而不是框架来处理。如果这个框架不断增长，使用10个甚至100个网站，这将成为维护的绝对噩梦，您的框架最终看起来不像框架，更像是特定于解决方案的产品。使用（1）是一个更清洁的解决方案。基本上保持您的框架可重用和解决方案无关。
如果您正在设计一个将被许多不同项目使用的框架，并且设计为可以使用一段时间，我建议您阅读Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (2nd Edition)
答案 2 :(得分：0)
在我看来，创建基类并为站点特定代码使用覆盖是一种更好的设计。虽然他们可以做到这一点，但似乎扩展方法似乎并不适合这种类型的操作。
现在，如果您正在寻找一种在不同网站上使用共享框架获取不同值的方法，那么web.config似乎可以满足这种需求。每个站点都有自己的Web.Config，您可以在那里填充所需的特定属性值，并且只有一个函数来检索该值吗？
答案 3 :(得分：0)
我会选择1，因为它保持框架的一般（和可重用）和特定的功能，如果我是维护程序员，我会在哪里使用。
为了共享功能，我将创建一个特定包装器派生自的基础包装类。