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

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

一、框架作者

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

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

二、单向婚姻

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

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

三、风险

风险可归纳为如下:

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

四、解决方案

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

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

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

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

五、不得不接受的依赖

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