Web项目类结构

Question

我认为这是一个很好的问题，但我不能百分之百肯定。如果太模糊的话请打个号。

我在许多网站上工作过，在这些网站中，公共框架类被覆盖。

由于我现在主要在.net工作，所以例子包括Page、Masterpage、UserControl、DbContext等。我相信这可以适用于任何语言。

有时，我可以理解为什么要这样做，我用实体框架的DbContext来包含一些日志代码。

不过，我不明白为什么要创建这些基类。因为我继承了大部分的网站，我真的不能问为什么。

我的问题是:当创建一个新站点来覆盖上面提到的公共框架类时，这是一个好主意/实践吗？这样做是否会被认为是一种旧的方式？

Answer 1

不这不是个好主意。除非您正在做一项非常特殊的工作，否则您不需要重写框架主类。富框架的问题。.net和java是基于您主要使用的部分来理解框架的。只有在此之后，框架才会减少您的工作负荷。这些框架是由顶级工程师设计的，所以如果您需要覆盖大量的框架，您可能不知道要寻找的特性在哪里，也不知道如何实现它。我在某个地方读到，时间就像钱：

1. 你可以花它(做某事)。
2. 您可以保存它(使用适当的工具)
3. 你可以投资(现在就花一些钱，以后再存更多)。

Answer 2

当您创建一个应用程序时，您所做的大部分工作应该是独立于框架的。框架应该是一个侧面的细节，而不是应用程序的核心部分。把它当作一种传递机制吧。数据库和诸如此类的也是如此。如果您创建了适当的边界，您将能够切换数据库、UI、路由框架等，而不必重写应用程序。

这意味着，一般来说，让您的应用程序处理从包边界之外的东西继承的类不是一个好主意。很难创建更紧密的耦合或更大的依赖，然后继承。(尤指伐木中的混合)似乎是错误的。

在日志主题上--在DbContext中放置哪些日志代码时要非常小心。如果这个DbContext使用一些很好的logger接口，那么它可以工作。否则，你可能违反了单一责任原则。

Answer 3

覆盖框架类不是一个好主意，即使框架的作者应该这样做。“总是喜欢组合而不是继承”--众所周知的规则。重写框架代码使您的代码更加依赖并与框架代码紧密耦合。

请注意："Masterpage“名称看起来像”上帝-对象“反模式案例。