手中无框架，心中有框架

一提起框架，咱们平时用java开发的程序员一下就想起几个常用框架：Spring MVC、Spring、MyBatis、Hibernate等等，说起每个框架比较典型的特性滔滔不绝，了然于心，像Spring的IOC、DI、AOP，Spring MVC的数据绑定，MyBatis的一对多、多对一关系的处理等等，好像只有把这些内容挂在嘴边才能显得自己确实掌握了这些框架，并且可以成为聊天、面试的谈资，但当我问起IOC实现原理、核心思想、当初是为了解决什么问题才产生了这么个概念，得到的回答是：“这是控制反转，控制反转的意思就是……。”依然是在解释概念。并没有真正的回答问题。

再比如Spring MVC的数据绑定：

---

@RequestMapping(value="/method", method=RequestMethod.POST)
public String mothod(@RequestParam("a") String a, @RequestParam("b") String b)

---

类似这样的写法，可能有的小伙伴发现，在开发的时候，其实这样写也行：

---

@RequestMapping(value="/method", method=RequestMethod.POST)
public String mothod(String a,String b)

---

这样写，变量a和变量b也能准确的绑定数据，没发现这个现象倒也罢了，发现后竟然也不好奇：这是什么原理？因为很明显，如果Spring只是单纯的用反射，是达不到这个效果的，反射，是没有办法获取到【方法的参数名】的，所以通过反射，是不可能知道哪个参数变量是a，哪个参数变量是b，如果不加注解就没办法准确的把a和b的值分别绑定到这两个参数上，如果知道这个知识的小伙伴，依然对Spring的这个现象不好奇，那我真的要好奇了，我好奇这些小伙伴为什么不好奇。反正我确实在《Java SSM定制大众点评App后台》中表现出了我的好奇。反正我身边确实有不好奇的同事，我和他说完现象和原理后，他：呵呵，这时我TM深刻的体会了一把：聊天止于呵呵。

曾经在一档求职类节目上，竟然发现了同类，很是欣喜，就看看这位兄弟是怎么在现场发挥的，开场会放一段VCR，是他的自我介绍，我觉得挺有意思，大概的意思是：无论什么设计模式、第几范式、什么框架统统不在话下，项目到手，统统用上。当时我就感觉说的像是在糊墙，水泥沙浆尽管往上糊。当然，我没办法和这位兄弟继续讨论这个话题，但我想会有小伙伴和这位的想法是差不多的，用自己掌握了多少种技术来武装自己，在项目上堆砌自己掌握的技术来证明自己掌握了。最后导致项目除了他本人，其他人是很难接手维护的，然后为此而沾沾自喜，并且觉得是不是其他人的技术太薄弱了，所以才没办法接手自己的事情。

但其实我们是忘却了本来的目的，原本要解决的问题，只是单纯的、不停的修炼外功，而忘了静下心来思考，修炼内功。比如思考：要开发的系统需要解决的是什么问题才用的这个框架，这个框架用在这个系统上真的好吗？是不是只是听别人说这个框架好，其实我并不知道它好不好，别人说这个框架好是因为帮助他们解决了什么问题？而他们遇到的问题其实和我现在遇到的问题并不相同,所以他们的观点并不能代表我现在的情况。用了这么多种框架和技术在系统上，就是为了让系统更难维护？

那么如果只是单纯的修炼外功，我就称之为是手上、嘴上都是有框架的，但心中是无框架的。相当于佛家的人生三重境界中的第一重：看山是山，看水是水。在这里就是看技术是技术，看框架是框架。还依然是停留在框架的表面，只是单纯的使用框架，为了技术而技术，在努力的解释一些概念而不得要领。

当然，工作一段时间后，有些小伙伴渐渐意识到，应该通过官方文档、看源码或者其他形式去了解框架更深层次的东西，这时会发现其实框架的底层是充分的利用了java的特性来帮我们解决平时要解决的问题，比如分层、解耦、复用框架封装好的功能来减少开发成本，同时也是一种约定，一种规范，公认的流行框架，如何将框架应用在项目上，不同的人在这个上的理解应该是大致相同，减少学习与沟通的成本，进了一家新公司，如果这家公司用的是流行框架，那很快就能上手工作，如果是公司自己内部私有的框架，那还需要重新学习这个框架的使用方法、开发规范，需要入乡随俗。

渐渐你积累了一些框架源代码中体现出来的思想，明白框架是在解决什么问题，为了解决这些问题，运用了什么样的手段和java特性，框架整体的代码结构是不是在保持着高内聚、低耦合的风格，是不是尽量做到开闭原则，在应用设计模式的时候是不是也是出于这些目的，而不是像我们中的一些小伙伴无端的为了用设计模式而用设计模式，也就是说，框架不光提供了我们所需功能，同时它自己还得保持良好的代码结构与风格，因为它也是由人开发的，一样会有BUG，一样需要维护并升级版本，如果不讲究，那样庞大的代码量，基本上维护不了两次就得扔了。这里的“两次”只是个虚指，真的能维护2次我真的OZR了，维护如此体量的烂代码2次比开发1次良好代码的框架更让我佩服，这也正是我们看框架源码的价值所在。说到这个，目前为止还没有和大家一起真正的讨论过框架源码，之前都还是忙着分享框架在实战中的应用，最多是为了解决框架应用时出现的问题、或是为了去了解框架在应用java什么特性才去追踪的源码，这还不算是真正的“看”源码，因为分享实战其实对新手入门确实很有帮助，不可能指望新手可以对着框架源码指点江山，如果你是天才，别理我说的这句话。后面希望有机会和这些成长起来的、当初的新手、如今已入门的小伙伴们一起讨论“源码赏析”这样的事。

基于对框架的这些认识，有人会尝试着自己也玩一玩java的这些特性，来探索框架背后的故事，比如MyBatis的接口式编程，是利用java的动态代理，这个我在《通过自动回复机器人学Mybatis---加强版》里仔细的和大家一起玩了一把。

再比如，MyBatis的一对多和多对一关系的配置，如果单纯从用的角度去看配置，那不过是在记忆一种配置规则，MyBatis要求我们这样配我们只能这样配，不然MyBatis不工作，记住这些不过是证明你用过，去公司可以立刻用这个框架上手干体力活了而已，而我们现在可以考虑的是：如果我们自己来实现MyBatis这个功能，为了将一个二维表的结果集映射成java对象来体现一对多、多对一的关系，我们可能也得要求使用者配这个参数，配那个参数，不然确实没办法映射，这个时候你再去看MyBatis所要求的配置，很顺眼、很合理，你一眼就看穿，配置这些内容将会起到什么作用，框架拿到这些配置大致会用来干嘛，然后为了证实自己的想法，还可以到源码里一探究竟。

这个时候，不再是那夸夸其谈表面概念的毛头小子，现在是手中有框架，心中也有框架，这时达到的是第二重境界：看山不是山，看水不是水。看技术不是技术，看框架不是框架，也就是说，这时你感觉到，你看框架和以前不太一样了，你看到的是框架背后的东西。

最难理解的是第三重境界：看山还是山，看水还是水。因为这一重人生境界不光难以企及，甚至难以理解。但我还是想在这一重境界再去看看框架，谈谈本人陋见。

这一重境界的人，再去看框架，不过就是框架，是用来解决问题的手段和工具，框架应为我所用，而我不应被其所累，深陷其中，工具顺手就用，也就是框架所能解决的问题，与面临的问题契合度很高，那就采用这个框架，如果工具不顺手，那就从工具箱里换一个顺手的，如果工具箱里没有合适的，完全有能力自己造一个，比如zTree，据zTree的作者自己介绍，他就是在工作中需要一个树插件，但没有特别吻合他需求的，这是个前端牛人，在这种情况下，一言不合就基于jQuery自己开发了zTree，随着不断的维护和完善，现在的功能已经非常强大，在本人分享定制大众点评的后台内容时，用zTree实现了相对较复杂的权限维护功能，就体现了zTree的强大。

而在InfoQ独家发售的《聊聊架构》这本书的最后一章里，作者谈了对事务的看法，和咱们这里说的第三重境界是一个道理，我这里大体描述一下书中所表达的意思：人们对数据库事务过度的依赖，导致架构拆分的困难，文中以银行转账为例，A向B转账100元这一过程，A账户-100元，B账户+100元，我们平时利用数据库事务的做法，其实是把这种业务的完整性保证转嫁给了数据库，导致当A账户和B账户不在同一个数据库里时，感觉处理起来很困难，而数据库原本应该保证的只是单条数据的保存，过度的依赖数据库事务来保证业务上的事务，就会出现这种情况，看透这个本质后，不过就是保证“一手交钱，一手交货”而已，只不过这个时候不是由数据库来保证，而是由数据库服务的调用者自己来保证，这里指的就是软件自身。然后如何保证，那是更细节的问题，在这里就不讨论了，有兴趣的可以自己去看书里的阐述。这里只是拿这件事举个栗子，超越数据库事务的限制，和咱们这里超越框架的限制，这样的思维方式是不是一个道理？

通过上述的例子来看看达到这一境界的人们，是何等的淡定从容，这不光是技术能力的问题，这需要居高临下的看待问题，明白技术和框架到底是为什么而服务。而如果把掌握的技术和框架当成炫耀的资本，不停的在项目上采用新的框架，却没有达成任何目的，没有丝毫解决问题的价值，那就算是有这个技术能力，也不大可能编写出造福程序员的工具，而更有可能制造出伤人的武器，因为这其实无论在人生的境界还是软件的境界，都是停留在第二重境界的表现，而且表现的还有点极端：看什么都不对劲，就自己最牛。在这种情况下让我去理解“看山不是山，看水不是水”，真的一下就联想到“鼻子不是鼻子脸不是脸”，身边的人都没自己懂框架，好像只有自己是唯一的一眼看穿框架的人。我这里为什么要强调一下人生的境界，因为软件的世界是来源于生活，是人生的一种折射，人们打牌时经常会说：牌品如人品，其实在软件上的表现，又何尝不是呢？这里给自己的名字打个广告：刚刚这些观点正是我叫【源生活】的原因，而且不光是来源于生活，同时也离不开生活，在这里顺便感谢一下家人在生活上的照顾和对我工作的支持，而我又利用在工作中的思考，提高工作效率而节省下时间，用来多去陪陪家人，相辅相成，好~~~~收！还是回到框架这件事上来。

这里没有贬低框架和技术的意思，只是可能没必要把框架供奉的高高在上，离开框架就寸步难行，因为再优秀的框架也不是包治百病可以解决所有问题，每个人面临的问题都各不相同，框架不过是解决了共性的问题，可能还有个性的问题需要解决，某个框架不过是其中一个备选方案，框架，就真的只是个框架。用人生的三重境界来比喻对框架的态度只是一时兴起、一家之言，每个人心里都有自己的一套解读方式，欢迎大家来交流有趣的想法。

那么第三重境界，在咱们这个话题里，我把它称为【手中无框架，心中有框架】，并不是说真的手上什么都没有，白手起家，而是说无论是用框架也罢，不用框架也罢，用流行框架也罢，用老的框架也罢，心里是有个无形的框架做为评判标准，以更好的解决问题为目的，如何选择不必纠结。框架------还是那个框架，而心------已更豁达。