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

均为原创,读架构整洁之道的笔记。

包含了部分自己的理解,包含了原书中至少70%的知识点。
完整笔记,各位老哥友链加起来吧。
我的博客地址:www.yuque.com/_huangkuan


框架在大多数时候是好事,它们非常有用,而且免费。

但框架不等同于架构,尽管有些框架确实以此为目标。

框架作者

大部分框架作者愿意免费提供自己的工作成果,是因为想要回馈社会和社群,这值得鼓励,但不管它们的行为多么高尚,恐怕也没有提供针对你个人的最佳方案。

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

当然,这些问题可能和其他人遇到的问题大体一致,因为如果不是这样,框架就不会这么流行了,正是因为这些重合性,框架才这么有用。

单向婚姻

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

细想,当我们选择一个框架时,就需要完整的阅读其文档,这个文档中,作者和使用者会对我们提出一些应用整合的建议,一般来说,这些建议就是要求我们围绕着这套框架来设计自己的系统架构。比如,框架作者会建议我们基于框架的基类,来创建派生类(PHP框架中的控制器),并在业务对象中引入一些框架工具(PHP框架中一些辅助函数),框架作者还会不停的催促我们将应用和框架结合得越紧密越好。

对于框架作者来说,应用程序和框架耦合没有风险,毕竟他是作者,对框架有着绝对控制权,强耦合是应该的。

与此同时,作者希望我们的应用程序和框架紧密结合,因为这意味着脱离框架会很难。对于框架作者来说,没有什么比让一堆用户心甘情愿地基于他的框架基类,来构建派生类更自豪的事情了。

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

风险

那么我们究竟要承担哪些风险呢?至少有下列几项

  • 框架自身的设计并不是特别正确。框架本身可能经常违反依赖关系原则。比如,框架可能会要求我们在核心业务逻辑中,引入框架自身提供的代码,使其将框架耦合到我们内层策略中。而我们一旦引入,就再也离不开该框架了,这就像戴上了结婚戒指,从此一生不离不弃。
  • 框架可能会帮助我们实现一些应用早期功能,但随着产品的成熟,功能要求很可能超过框架能力,而且随着时间推移,我们会发现,我们与框架的斗争时间,比和业务斗争时间更多。
  • 框架可能朝着我们不需要的方向演进,我们可能被迫升级到一个并不需要的新版本,甚至会发现之前的功能消失了。
  • 未来我们可能会想切到另一个更好的框架上去。

解决方案

请不要嫁给框架。这就是解决方案。

我们可以使用框架,但要时刻警惕,别被它拖住。我们应该限制它只让它出现在外层,不要让它进入内圈。

如果要求我们基于它提供的基类来创建派生类,就请不要这样做。解决办法是创建一个代理类,同时把这些代理类当作业务逻辑插件来管理。具体的业务对象,应该对框架的存在完全不知情。

不得不接受的依赖

有一些框架是避免不了使用的,比如C++中,那么STL就是很难避免使用的,比如Java,那么标准类库也是不太可能避免使用的。

这很正常,但这仍然应该是你主动选择的结果。我们必须明白,一旦在项目中引入了一个框架,很有可能在整个生命周期中都要依赖于它,不管后来会发生什么变化,这个决定都很难更改了。因此,不应该草率的做出决定。

本章小结

当我们面临框架选择时,不要草率做出决定,应该首先看看是否可以部分采用以增加了解。另外要尽可能地,长时间的将框架留在架构边界之外,越久越好。因为也许你不用买奶牛,也可以喝到牛奶。

本作品采用《CC 协议》,转载必须注明作者和本文链接
《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!