不要嫁给框架：用代理类隔离依赖，并对不可避免的依赖保持主动选择

应对[[框架作者与用户的单向婚姻及四项具体风险]]的解决方案很直白：不要嫁给框架。框架可以用，但要时刻保持警惕、别被它拖住——该把框架当作架构最外圈的一个实现细节来用，不让它渗进内圈。如果框架要求根据它的基类创建派生类，就不要照做，而是创造代理类，把这些代理类当作业务逻辑的插件来管理；不能让框架污染核心代码，要依据依赖关系原则把它们当作核心代码的插件对待。以Spring为例：作为依赖注入框架它很好用，可以用它来自动连接应用里各种依赖关系，但千万别在业务对象里到处写@autowired注解——业务对象理应对Spring的存在完全不知情；反过来利用Spring把依赖关系注入到Main组件里则完全没问题，因为Main组件本就是系统架构里最低层、依赖最多的组件，它依赖Spring不构成风险。当然，有些框架事实上无法避免——用C++几乎躲不开STL，用Java几乎躲不开标准类库，这很正常，但即便如此，这依然应该是一个主动做出的选择，而非顺手草率的决定：因为一旦在项目里引入一个框架，很可能在整个项目生命周期里都要依赖它，之后不管情况怎么变，这个决定都很难更改。面对框架选择，最好先局部性地采用它来增加了解，而不是一上来就全身心投入，并且尽可能长时间地把框架挡在架构边界之外——说不定你根本不用买下整头奶牛，也能喝到牛奶。