就現代程式開發而言,只要談到框架,多半令人感到沉重,這主要是來自兩個方面:其一是應用程式到了一定規模,須基於某套半成品,才能加速開發;其二則是半成品本身,為了應付各式需求,本身往往也龐大到令人窒息。
更糟糕的是,開發者要接觸的半成品,經常不會只有一種,想要樣樣精通基本上是不可能的!
可以帶一下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中遇到的什麼問題?這些答案,也決定要不要重構新的模版功能。
也就是說,沒必要全面瞭解一個框架,再來使用框架,也沒必要使用框架的全部功能。認識多少、就用多少,其餘暫且基於既有熟悉的技術也無妨。
在一知半解的情況下,勉強使用某些框架功能,反而是危險的。也許是忽略了生命週期,而造成除錯困難;或者是忽略了技術細節,而造成效能低弱,更糟的情況,可能因為不知道各元件環節之間如何銜接,而造成了安全漏洞。
為了避免一知半解,在調查功能細節的過程,必須採取系統性的作法,單靠網路上的零散文件,只會造成困擾,改為透過一本專書是不錯的選擇。
因為,若框架有些歷史了,一本專書往往會交代一些各版本的變異,以及最佳實踐的變化,甚至是中心思想或者既有典範的轉移等,而這些在決定框架功能的用與不用之時,會是個參考基準。
篩選必要功能的方式
許多開發者都認為,框架可以視為程式語言的延伸,只不過,若生態系很活躍,而框架本身也蓬勃發展的話,這套語言的延伸,很容易擴展到像是沒有邊界的狀態,而對於這類框架,想要全面掌握是沒有意義也不可能的,因而必須要有方式來篩選必要功能。
所以,掌握一門框架的中心思想是個出發點。因為,理解底層或者實作方式,可以大致構築出框架各個功能的運作原理。舉例來說,如果有個原型應用程式,我們可以試著找出框架的最小集合,重構應用程式來套用那個最小集合;接著,系統性地吸收框架知識,找出令原型應用程式能獲得益處的功能,逐步重構應用程式來套用那些功能。
最重要的是謹記,別試圖用上全部的功能,也不用試著追逐每個新增的功能,而是懂得如何篩選出對應用程式本身來說的必要功能,如此就算框架是龐大的,對你來說也會是簡潔的!
專欄作者
熱門新聞
2024-09-29
2024-10-01
2024-10-01
2024-10-01
2024-10-01
2024-10-03
2024-09-29