筛选框架必要功能
现行的开发框架种类繁多，而每套框架本身也可能相当庞大，该如何妥善应用？势必要适当抉择所需功能，如此一来，就算框架是庞大的，对你来说也会是简洁的！
按赞加入iThome粉丝团
文/林信良 | 2018-01-21发表
就现代程式开发而言，只要谈到框架，多半令人感到沉重，这主要是来自两个方面：其一是应用程式到了一定规模，须基于某套半成品，才能加速开发；其二则是半成品本身，为了应付各式需求，本身往往也庞大到令人窒息。
更糟糕的是，开发者要接触的半成品，经常不会只有一种，想要样样精通基本上是不可能的！
可以带一下Spring MVC吗？
在Java全盛时期，开放原始码专案百花齐放的那个年代，有着各式各样的框架，而且各自发展迅速，版本变更快到开发者不得不停下脚步，思考追逐新框架或新版本的意义究竟何在？
仔细想想，有些新功能用来省事，其实只是换了个新封装，却重复著旧的模式；有的功能则是基于新观念，有待社群进一步地验证可行性。无论是哪个，似乎都不能作为继续亦步亦趋的理由。
在工作也暂时用不上的情况下，被我暂时放生的框架之一是Spring，在Spring 2.0 之后就不常接触。过了多年，现在5.0都出了，虽然大致知道主打的特点是什么，但并未去玩弄过细节。直到不久前，一门Servlet/JSP教育训练接近尾声时，有学员闲聊时谈到：“可以带一下Spring MVC吗？很多同事接下来必须使用，只是东西超多，不知从何下手！”
我内心的OS是：“呃！都接近课程尾声了，还能怎样？”对于这类需求，通常会被我婉转拒绝，而且，都这么多年没碰Spring MVC了啊！然而，脑袋中迅速地闪过了几个画面，嘴角一滑，就开口说道：“好啊！我抽一、两个小时带一下，至于原本课程后面的OOXX，自己看书也可以！”
这突如其来的勇气，倒也不是信口开河，虽然是Servlet/JSP教育训练，然而，使用了一个MVC架构的Web应用程式，贯穿整个课程，在适当阶段也都运用重构，切分出Facade、DAO等各式元件，正好Web层可以套用Spring MVC，而中间层的元件可以用Spring DI来解决。
然而，两个小时左右的时间毕竟有限，必须筛选框架的功能，只讲解必要的部份。为了衔接课程，我还是先在web.xml中设定DispatcherServlet，然后，其余部份尽量采零配置（zero configuration），幸而早就以Servlet/JSP自干出MVC架构的范例，因此，对于零配置时采用的惯例（Convention）配置是什么，学员并不难理解。
熟悉框架底层
因为，Spring MVC有一点不错的设计，那就是控制器的方法，可以直接注入Servlet API，像是HttpServletRequest、HttpServletResponse。这意味着：直接复制原Servlet中的程式码，放到Spring控制器中，重新命名方法、下几个标注、自动注入Facade元件，控制器就可以动起来了。
至于HttpServletRequest、HttpServletResponse做什么用的？在接下来的课程，当然就不必再解释，后续只要检视程式码，如果方法中实际上只用到HttpSession，就只要删掉HttpServletRequest、HttpServletResponse，改注入HttpSession即可。类似地，若只用到HttpServletRequest，此时，我们就只需要注入HttpServletRequest；若只用到HttpServletResponse，就只需注入HttpServletResponse。
实际上，如果方法中只需要请求参数呢？方法参数的部份，就改标注@RequestParam；如果最后只是转发（forward），那就return一个字串，而请求参数的注入、转发API什么的细节，就可以带入前端控制器模式（Front controller）的概念了，并可以一并解释Spring DI容器、自动扫描标准、自动绑定的概念，是如何由DispatcherServlet开始这一切的。
这就是为何开发者常说的“要知道框架底层原理”。Spring MVC是基于Servlet，若熟悉Servlet API，在有个Servlet/JSP建构的Web应用程式，而且已经符合MVC架构，基于Servlet API筛选出Spring MVC中最基本元素，去掉不必要的配置，才能马上感受到框架的好处。
基于框架的持续重构
嗯？这样就算使用Spring MVC吗？为什么不算？如果打从一开始，只在控制器的方法中，注入HttpServletRequest、HttpServletResponse，就算还没用Spring DI来组合Facade、DAO等元件，此时，只要应用程式能如常运作，就是使用Spring MVC，没有人规定须用到什么程度、用了哪些API，才算是使用了一个框架！
当然，有人会说，这太浪费框架的功能了，是没错！只是，框架的功能是否有价值，在于它能不能为你的应用程式带来益处。
例如，使用@Autowired自动绑定Facade元件，能使应用程式省去自行组合依赖关系的麻烦，又能使程式架构清楚；而使用@RequestParam，一眼就知道该变量代表请求参数；若使用@PathVariable，我们马上就知道是路径变量，那就不用特别注入HttpServletRequest。因而，值得基于这些功能来重构应用程式。
所以，这也可以用来判定一个框架，是否适合你的方式。框架应该要有个最小集合，而这个最小集合，最好可以基于开发者既有的技术背景，在略为重构（原型）应用程式，以使用此最小集合后，就能使应用程式运行起来，之后随着对框架认识的越多，在判定框架中的特定功能是否适用，之后，再逐步重构应用程式能使用该功能。
就像Spring MVC呈现技术不一定要用JSP，那么，该使用其他模版技术吗？这就要问你自己了，对于JSP有什么不满吗？对于想使用的模版技术，又认识得够多吗？它又能解决你在JSP中遇到的什么问题？这些答案，也决定要不要重构新的模版功能。
也就是说，没必要全面了解一个框架，再来使用框架，也没必要使用框架的全部功能。认识多少、就用多少，其余暂且基于既有熟悉的技术也无妨。
在一知半解的情况下，勉强使用某些框架功能，反而是危险的。也许是忽略了生命周期，而造成除错困难；或者是忽略了技术细节，而造成效能低弱，更糟的情况，可能因为不知道各元件环节之间如何衔接，而造成了安全漏洞。
为了避免一知半解，在调查功能细节的过程，必须采取系统性的作法，单靠网络上的零散文件，只会造成困扰，改为透过一本专书是不错的选择。
因为，若框架有些历史了，一本专书往往会交代一些各版本的变异，以及最佳实践的变化，甚至是中心思想或者既有典范的转移等，而这些在决定框架功能的用与不用之时，会是个参考基准。
筛选必要功能的方式
许多开发者都认为，框架可以视为程式语言的延伸，只不过，若生态系很活跃，而框架本身也蓬勃发展的话，这套语言的延伸，很容易扩展到像是没有边界的状态，而对于这类框架，想要全面掌握是没有意义也不可能的，因而必须要有方式来筛选必要功能。
所以，掌握一门框架的中心思想是个出发点。因为，理解底层或者实作方式，可以大致构筑出框架各个功能的运作原理。举例来说，如果有个原型应用程式，我们可以试着找出框架的最小集合，重构应用程式来套用那个最小集合；接着，系统性地吸收框架知识，找出令原型应用程式能获得益处的功能，逐步重构应用程式来套用那些功能。
最重要的是谨记，别试图用上全部的功能，也不用试着追逐每个新增的功能，而是懂得如何筛选出对应用程式本身来说的必要功能，如此就算框架是庞大的，对你来说也会是简洁的！
https://www.ithome.com.tw/voice/120504
值得思考的问题与观点
思考追逐新框架或新版本的意义究竟何在？
只要应用程式能如常运作，就是使用Spring MVC，没有人规定须用到什么程度、用了哪些API，才算是使用了一个框架！
框架的功能是否有价值，在于它能不能为你的应用程式带来益处。
没必要全面了解一个框架，再来使用框架，也没必要使用框架的全部功能。认识多少、就用多少，其余暂且基于既有熟悉的技术也无妨。
别试图用上全部的功能，也不用试着追逐每个新增的功能，而是懂得如何筛选出对应用程式本身来说的必要功能，如此就算框架是庞大的，对你来说也会是简洁的！