《架构整洁之道》之应用程序框架是实现细节

框架并不等同于系统架构——尽管有些框架确实以此为目标。

一、框架作者

大部分框架的作者愿意免费提供自己的工作成果,是因为他们想要帮助整个社群,想要回馈社会。这值得鼓励,但不管这些作者的动机有多么高尚,恐怕也并没有提供针对你个人的最佳方案。即使他们想,也做不到,因为他们并不了解你,也不了解你遇到的问题。

这些框架作者所了解的都是他们自己遇到的问题,可能还包括亲戚朋友所遇到的。他们创造框架的目的是解决这些问题——而不是解决你遇到的问题。

二、单向婚姻

我们与框架作者之间的关系是非常不对等的。我们要采用某个框架就意味着自己要遵守一大堆约定,但框架作者却完全不需要为我们遵守什么约定。

换句话说,框架作者想让我们与框架订终身——这相当于我们要对他们的框架做一个巨大而长期的承诺,而在任何情况下框架作者都不会对我们做出同样的承诺。这种婚姻是单向的。我们要承担所有的风险,而框架作者则没有任何风险。

三、风险

风险可归纳为如下:

  • 框架自身的架构设计很多时候并不是特别正确的。框架本身可能经常违背依赖关系原则。
  • 框架可能会帮助我们实现一些应用程序的早期功能。
  • 框架本身可能朝着我们不需要的方向演进。
  • 未来我们可能会想要切换到一个更新、更好的框架上。

四、解决方案

解决方案是什么呢?请不要嫁给框架。

我们可以使用框架——但要时刻警惕,别被它拖住。我们应该将框架作为架构最外圈的一个实现细节来使用,不要让它们进入内圈。

如果框架要求我们根据它们的基类来创建派生类,就请不要这样做。我们可以创造一些代理类,同时把这些代理类当作业务逻辑的插件来管理。

另外,不要让框架污染我们的核心代码,应该依据依赖关系原则,将它们当作核心代码的插件来管理。

五、不得不接受的依赖

有一些框架是避免不了使用的。但这应该是你主动选择的结果。你必须明白,如果一旦在项目中引入一个框架,很有可能在整个生命周期中都要依赖于它,不管后来情形怎么变化,这个决定都很难更改了。因此,不应该草率地做出决定。

文章目录
  1. 一、框架作者
  2. 二、单向婚姻
  3. 三、风险
  4. 四、解决方案
  5. 五、不得不接受的依赖