那我就唱反调了…
假设有一个框架服务2或3个不同的网站。框架的一个基本功能是处理对某个DB的所有调用。当进行数据库调用时，网站调用框架数据源对象并获得一个通用框架数据对象。
现在对于网站检索属性/方法是特定于它的需求，我们有两个解决方案的选择。
-
创建一个新的类，扩展或包装通用数据对象，展示更多领域友好的属性& &;保留任何域
-
不是创建一个新的类，而是在框架内创建扩展方法来服务这些网站。所以一切都是包含在框架内，可以在网站之间共享
为了澄清，这里有一些例子:属性:
- NewObject。GetSiteSpecificProperty
- GenericObject.GetProperty("GetSiteSpecificProperty")或GenericObject.GetSiteSpecificProperty()
- NewObject.DoSomethingSpecificToThisWebsite ()
- GenericObject.DoSomethingSpecificToThisWebsite ()
那么你会选择什么解决方案呢?1还是2?
欢呼。
在我看来，当设计一个框架时，你应该尽可能多地将解决方案特定的方面保留在框架之外，如果可能的话，让调用实体来处理。
现在我不太确定你的框架将如何使用或有多少不同的网站项目，但与选项(2)去意味着现在每当一个新的网站被添加的框架现在需要去做的工作，以完成这个功能。以自定义方式使用框架的工作应该由网站处理，而不是由框架处理。如果这个框架发展到使用10个甚至100个网站，这将成为维护的绝对噩梦，并且你的框架最终看起来不像一个框架，而更像一个解决方案特定的产品。使用(1)是一个更干净的解决方案。基本上要保持框架的可重用性和解决方案无关性。
如果你正在设计一个框架，它将被许多不同的项目使用，并且被设计为一段时间，我建议你阅读框架设计指南:可重用。net库的惯例，习惯用法和模式(第二版)
一般来说，如果您控制要扩展的类的源，我会通过继承而不是扩展方法来扩展它。扩展方法非常适合为你无法控制的类添加自定义功能，比如。net内置(String, Enum, IEnumerable)和其他第三方对象。然而，它们可能很难组织，而且它们在技术上是静态方法，为了提高启动性能和内存占用，您通常希望将其最小化。
如果使用扩展，你可能会发现自己陷入命名空间和方法解析的麻烦;假设您将扩展方法放入特定于站点的库中。如果一个站点必须做与另一个站点相同的特定于站点的事情，您必须在另一个站点中包含包含扩展方法的站点库(暴露您可能不希望代码知道的其他事情，可能包含对象或扩展的副本)，或者克隆代码(违反DRY)。
在我看来，创建一个基类并为您的站点特定代码使用覆盖是一个更好的设计。虽然它们可以做到这一点，但扩展方法似乎不适合这种类型的操作。
现在，如果你正在寻找一种方法，在不同的网站上使用共享框架获得不同的值，似乎是网络。Config将满足这种需求。每个站点都有自己的Web。配置，您可以填充特定的属性值，您需要在那里，并有一个单一的函数来检索该值吗?
我会选择1，因为它保持了框架的通用性(和可重用性)和特定的功能，如果我是一个维护程序员，我将看到它。
为了共享功能，我将创建一个基包装器类，特定的包装器从它派生。