框架作者与用户的"单向婚姻"，及四项具体风险

框架流行、有用、免费，但框架不等于系统架构——尽管有些框架确实以取代架构为目标。多数框架作者免费分享成果是出于回馈社群的善意，这值得鼓励，但无论动机多高尚，他们提供的都不是针对你个人的最佳方案——因为他们只了解自己（以及亲友）遇到的问题，创造框架是为了解决那些问题，不是为了解决你的问题；框架之所以流行，是因为很多人的问题恰好和框架作者的问题足够相似。我们和框架作者之间的关系极不对等，作者称之为”单向婚姻”：采用一个框架意味着自己要遵守一整套约定（阅读文档、按框架建议围绕它设计系统架构、基于框架基类创建派生类、把框架工具引入业务对象），而框架作者完全不需要为我们遵守任何约定；对框架作者而言，让应用和框架强耦合毫无风险（他们对自己的框架拥有绝对控制权），反而是值得骄傲的事——耦合越紧，用户脱离框架就越难。这份不对等的婚姻背后藏着四类具体风险：一是框架自身的架构设计可能并不正确，甚至常常违反依赖关系原则，要求代码侵入业务对象乃至业务实体，一旦接受就再难脱身；二是框架能帮上产品早期开发的忙，但随产品成熟、功能需求超出框架能力范围后，与框架斗争所花的时间往往会超过它曾经帮忙的时间；三是框架本身可能朝不需要的方向演进，被迫升级到不想要的新版本，甚至旧功能悄悄消失或改变行为；四是未来可能想换到一个更新更好的框架，而当初的深度耦合会让这次迁移代价高昂。