【文章內(nèi)容簡(jiǎn)介】 的前端控制器對(duì)應(yīng)，這種模式稱為頁面控制器。頁面控制器和前端控制器實(shí)現(xiàn)實(shí)現(xiàn)之間的區(qū)別在于頁面控制器描述的往往是同一個(gè)頁面中（如類似于控制面板那樣的頁面）的處理邏輯，不能用于跨多個(gè)頁面對(duì)處理過程進(jìn)行控制或協(xié)調(diào)。它是一種 Poll 的模型。8圖 MVC結(jié)構(gòu)圖Spring MVC 框架是有一個(gè) MVC 框架，通過實(shí)現(xiàn) ModelViewController模式來很好地將數(shù)據(jù)、業(yè)務(wù)與展現(xiàn)進(jìn)行分離。從這樣一個(gè)角度來說，Spring MVC 和 Struts、Struts2 非常類似。Spring MVC 的設(shè)計(jì)是圍繞DispatcherServlet 展開的，DispatcherServlet 負(fù)責(zé)將請(qǐng)求派發(fā)到特定的handler。通過可配置的 handler mappings、view resolution、locale 以及theme resolution 來處理請(qǐng)求并且轉(zhuǎn)到對(duì)應(yīng)的視圖。Spring MVC 請(qǐng)求處理的整體流程如圖 。1. 用戶向服務(wù)器發(fā)送請(qǐng)求，請(qǐng)求被 Spring 前端控制 Servelt DispatcherServlet 捕獲；2. DispatcherServlet 對(duì)請(qǐng)求 URL 進(jìn)行解析，得到請(qǐng)求資源標(biāo)識(shí)符（URI）。然后根據(jù)該 URI，調(diào)用 HandlerMapping 獲得該 Handler 配置的所有相關(guān)的對(duì)象（包括 Handler 對(duì)象以及 Handler 對(duì)象對(duì)應(yīng)的攔截器），最后以HandlerExecutionChain 對(duì)象的形式返回；3. DispatcherServlet 根據(jù)獲得的 Handler，選擇一個(gè)合適的HandlerAdapter。（附注：如果成功獲得 HandlerAdapter 后，此時(shí)將開始執(zhí)行攔截器的 preHandler（...）方法）4. 提取 Request 中的模型數(shù)據(jù)，填充 Handler 入?yún)?，開始執(zhí)行9Handler（Controller）。 在填充 Handler 的入?yún)⑦^程中，根據(jù)你的配置，Spring 將幫你做一些額外的工作：HttpMessageConveter： 將請(qǐng)求消息（如 Json、xml 等數(shù)據(jù)）轉(zhuǎn)換成一個(gè)對(duì)象，將對(duì)象轉(zhuǎn)換為指定的響應(yīng)信息數(shù)據(jù)轉(zhuǎn)換：對(duì)請(qǐng)求消息進(jìn)行數(shù)據(jù)轉(zhuǎn)換。如 String 轉(zhuǎn)換成Integer、Double 等數(shù)據(jù)根式化：對(duì)請(qǐng)求消息進(jìn)行數(shù)據(jù)格式化。 如將字符串轉(zhuǎn)換成格式化數(shù)字或格式化日期等數(shù)據(jù)驗(yàn)證： 驗(yàn)證數(shù)據(jù)的有效性（長(zhǎng)度、格式等），驗(yàn)證結(jié)果存儲(chǔ)到BindingResult 或 Error 中5. Handler 執(zhí)行完成后，向 DispatcherServlet 返回一個(gè)ModelAndView 對(duì)象；6. 根據(jù)返回的 ModelAndView，選擇一個(gè)適合的 ViewResolver（必須是已經(jīng)注冊(cè)到 Spring 容器中的 ViewResolver）返回給 DispatcherServlet ；7. ViewResolver 結(jié)合 Model 和 View，來渲染視圖8. 將渲染結(jié)果返回給客戶端。圖 Spring MVC的請(qǐng)求處理流程10Spring3 MVC 的優(yōu)點(diǎn)：Spring3 MVC 使用簡(jiǎn)單，學(xué)習(xí)成本低。學(xué)習(xí)難度小于Struts2，Struts2 用不上的多余功能太多。呵呵，當(dāng)然這不是決定因素。Spring3 MVC 很容易就可以寫出性能優(yōu)秀的程序，Struts2 要處處小心才可以寫出性能優(yōu)秀的程序（指 MVC 部分）Spring3 MVC 的靈活是你無法想像的，Spring 框架的擴(kuò)展性有口皆碑，Spring3 MVC 當(dāng)然也不會(huì)落后，不會(huì)因使用了 MVC 框架而感到有任何的限制。文中系統(tǒng)使用 Spring3 MVC 作為基礎(chǔ)框架。 數(shù)據(jù)持久化與 Hibernate vs iBATIS數(shù)據(jù)持久化就是將內(nèi)存中的數(shù)據(jù)模型轉(zhuǎn)換為存儲(chǔ)模型,以及將存儲(chǔ)模型轉(zhuǎn)換為內(nèi)存中的數(shù)據(jù)模型的統(tǒng)稱. 數(shù)據(jù)模型可以是任何數(shù)據(jù)結(jié)構(gòu)或?qū)ο竽Ｐ?存儲(chǔ)模型可以是關(guān)系模型、XML、二進(jìn)制流等。 [4]Hibernate 是一個(gè)開放源代碼的對(duì)象關(guān)系映射框架，它對(duì) JDBC 進(jìn)行了非常輕量級(jí)的對(duì)象封裝，使得 Java 程序員可以隨心所欲的使用對(duì)象編程思維來操縱數(shù)據(jù)庫。 Hibernate 可以應(yīng)用在任何使用 JDBC 的場(chǎng)合，既可以在 Java的客戶端程序使用，也可以在 Servlet/JSP 的 Web 應(yīng)用中使用，最具革命意義的是，Hibernate 可以在應(yīng)用 EJB 的 J2EE 架構(gòu)中取代 CMP，完成數(shù)據(jù)持久化的重任。 [5]Hibernate 的核心接口一共有 5 個(gè)，分別為：Session、SessionFactory、Transaction、Query 和 5 個(gè)核心接口在任何開發(fā)中都會(huì)用到。通過這些接口，不僅可以對(duì)持久化對(duì)象進(jìn)行存取，還能夠進(jìn)行事務(wù)控制。下面對(duì)這五的核心接口分別加以介紹。Session 接口：Session 接口負(fù)責(zé)執(zhí)行被持久化對(duì)象的 CRUD 操作（CRUD的任務(wù)是完成與數(shù)據(jù)庫的交流，包含了很多常見的 SQL 語句。）。但需要注意的是 Session 對(duì)象是非線程安全的。同時(shí)，Hibernate 的 session 不同于 JSP應(yīng)用中的 session 這個(gè)術(shù)語時(shí)，其實(shí)指的是Hibernate 中的 session，而以后會(huì)將 HttpSesion 對(duì)象稱為用戶 session.SessionFactory 接口：SessionFactroy 接口負(fù)責(zé)初始化 當(dāng)數(shù)據(jù)存儲(chǔ)源的代理，并負(fù)責(zé)創(chuàng)建 Session 對(duì)象。這里用到了工廠模式。需要11注意的是 SessionFactory 并不是輕量級(jí)的，因?yàn)橐话闱闆r下，一個(gè)項(xiàng)目通常只需要一個(gè) SessionFactory 就夠，當(dāng)需要操作多個(gè)數(shù)據(jù)庫時(shí)，可以為每個(gè)數(shù)據(jù)庫指定一個(gè) SessionFactory.Configuration 接口：Configuration 接口負(fù)責(zé)配置并啟動(dòng) Hibernate，創(chuàng)建 SessionFactory 對(duì)象。在 Hibernate 的啟動(dòng)的過程中，Configuration類的實(shí)例首先定位映射文檔位置、讀取配置，然后創(chuàng)建 SessionFacTransaction 接口：Transaction 接口負(fù)責(zé)事務(wù)相關(guān)的操作。它是可選的，開發(fā)人員也可以設(shè)計(jì)編寫自己的底層事務(wù)處理代碼。Query 和 Criteria 接口：Query 和 Criteria 接口負(fù)責(zé)執(zhí)行各種數(shù)據(jù)庫查詢。它可以使用 HQL 語言或 SQL 語句兩種表達(dá)方式。Hibernate 具有以下特點(diǎn)： [6]（1） 對(duì)象/關(guān)系數(shù)據(jù)庫映射（ORM）它使用時(shí)只需要操縱對(duì)象，使開發(fā)更對(duì)象化，拋棄了數(shù)據(jù)庫中心的思想，完全的面向?qū)ο笏枷耄?） 透明持久化（persistent）帶有持久化狀態(tài)的、具有業(yè)務(wù)功能的單線程對(duì)象，此對(duì)象生存期很短。這些對(duì)象可能是普通的 JavaBeans/POJO，這個(gè)對(duì)象沒有實(shí)現(xiàn)第三方框架或者接口，唯一特殊的是他們正與（僅僅一個(gè)）Session 相關(guān)聯(lián)。一旦這個(gè) Session被關(guān)閉，這些對(duì)象就會(huì)脫離持久化狀態(tài)，這樣就可被應(yīng)用程序的任何層自由使用。（例如，用作跟表示層打交道的數(shù)據(jù)傳輸對(duì)象。） （3） 事務(wù) Transaction（） 應(yīng)用程序用來指定原子操作單元范圍的對(duì)象，它是單線程的，生命周期很短。它通過抽象將應(yīng)用從底層具體的 JDBC、JTA 以及 CORBA 事務(wù)隔離開。某些情況下，一個(gè) Session 之內(nèi)可能包含多個(gè) Transaction 對(duì)象。盡管是否使用該對(duì)象是可選的，但無論是使用底層的 API 還是使用 Transaction 對(duì)象，事務(wù)邊界的開啟與關(guān)閉是必不可少的。 （4） 它沒有侵入性，即所謂的輕量級(jí)框架（5） 移植性會(huì)很好（6） 緩存機(jī)制，提供一級(jí)緩存和二級(jí)緩存（7） 簡(jiǎn)潔的 HQL 編程12iBATIS 一詞來源于“inter”和“abatis”的組合，是一個(gè)由 Clinton Begin 在 2022 年發(fā)起的開放源代碼項(xiàng)目。于 2022 年 6 月 16 號(hào)被谷歌托管，改名為 MyBatis。是一個(gè)基于 SQL 映射支持 Java 和NET 的持久層框架。iBATIS 提供的持久層框架包括 SQL Maps 和 Data Access Object,同時(shí)還提供一個(gè)利用這個(gè)框架開發(fā)的 JPetStore 實(shí)例。相對(duì) Hibernate 和 ApacheOJB 等“一站式”O(jiān)RM 解決方案而言，iBATIS 是一種“半自動(dòng)化”的 ORM 實(shí)現(xiàn)。iBATIS 目前提供了三種語言實(shí)現(xiàn)的版本，包括：Java、.NET 以及 Ruby。 Hibernate 還是 Apache OJB，都對(duì)數(shù)據(jù)庫結(jié)構(gòu)提供了較為完整的封裝，提供了從 POJO 到數(shù)據(jù)庫表的全套映射機(jī)制。程序員往往只需定義好了 POJO 到數(shù)據(jù)庫表的映射關(guān)系，即可通過 Hibernate 或者 OJB 提供的方法完成持久層操作。程序員甚至不需要對(duì) SQL 的熟練掌握， Hibernate/OJB 會(huì)根據(jù)制定的存儲(chǔ)邏輯，自動(dòng)生成對(duì)應(yīng)的 SQL 并調(diào)用 JDBC 接口加以執(zhí)行。但 Hibernate 這種 ORM，在有些情況下存在不少缺陷：1． 系統(tǒng)的部分或全部數(shù)據(jù)來自現(xiàn)有數(shù)據(jù)庫，處于安全考慮，只對(duì)開發(fā)團(tuán)隊(duì)提供幾條 Select SQL（或存儲(chǔ)過程）以獲取所需數(shù)據(jù)，具體的表結(jié)構(gòu)不予公開。2． 開發(fā)規(guī)范中要求，所有牽涉到業(yè)務(wù)邏輯部分的數(shù)據(jù)庫操作，必須在數(shù)據(jù)庫層由存儲(chǔ)過程實(shí)現(xiàn)（就筆者工作所面向的金融行業(yè)而言，工商銀行、中國銀行、交通銀行，都在開發(fā)規(guī)范中嚴(yán)格指定）3． 系統(tǒng)數(shù)據(jù)處理量巨大，性能要求極為苛刻，這往往意味著我們必須通過經(jīng)過高度優(yōu)化的 SQL 語句（或存儲(chǔ)過程）才能達(dá)到系統(tǒng)性能設(shè)計(jì)指標(biāo)。面對(duì)這種需求，iBATIS 剛好可以解決。iBATIS 入門簡(jiǎn)單，即學(xué)即用 [7]，提供了數(shù)據(jù)庫查詢的自動(dòng)對(duì)象綁定功能，而且延續(xù)了很好的 SQL 使用經(jīng)驗(yàn)，對(duì)于沒有那么高的對(duì)象模型要求的項(xiàng)目來說，相當(dāng)完美。iBATIS 的缺點(diǎn)就是框架還是比較簡(jiǎn)陋，功能尚有缺失，雖然簡(jiǎn)化了數(shù)據(jù)綁定代碼，但是整個(gè)底層數(shù)據(jù)庫查詢實(shí)際還是要自己寫的，工作量也比較大，而且不太容易適應(yīng)快速數(shù)據(jù)庫修改。當(dāng)系統(tǒng)屬于二次開發(fā),無法對(duì)數(shù)據(jù)庫結(jié)構(gòu)做到控制和修改,那 iBATIS 的靈活性將比 Hibernate 更適合。系統(tǒng)數(shù)據(jù)處理量巨大，性能要求極為苛刻，這往往意味著我們必須通過經(jīng)過高度優(yōu)化的13SQL 語句（或存儲(chǔ)過程）才能達(dá)到系統(tǒng)性能設(shè)計(jì)指標(biāo)。在這種情況下 iBATIS會(huì)有更好的可控性和表現(xiàn) [8]。對(duì)于實(shí)際的開發(fā)進(jìn)行的比較：1． iBATIS 需要手寫 sql 語句，也可以生成一部分，Hibernate 則基本上可以自動(dòng)生成，偶爾會(huì)寫一些 Hql。同樣的需求,iBATIS 的工作量比 Hibernate 要大很多。類似的，如果涉及到數(shù)據(jù)庫字段的修改，Hibernate 修改的地方很少，而 iBATIS 要把那些 sql mapping 的地方一一修改。2. iBATIS 可以進(jìn)行細(xì)粒度的優(yōu)化比如說我有一個(gè)表，這個(gè)表有幾個(gè)或者幾十個(gè)字段，我需要更新其中的一個(gè)字段，iBATIS 很簡(jiǎn)單，執(zhí)行一個(gè) sql UPDATE TABLE_A SET column_1=column_1 WHERE id=id 但是用 Hibernate 的話就比較麻煩了,缺省的情況下 hibernate 會(huì)更新所有字段。 當(dāng)然我記得 hibernate 有一個(gè)選項(xiàng)可以控制只保存修改過的字段，但是我不太確定這個(gè)功能的負(fù)面效果。例如：我需要列出一個(gè)表的部分內(nèi)容，用 iBATIS 的時(shí)候，這里面的好處是可以少從數(shù)據(jù)庫讀很多數(shù)據(jù)，節(jié)省流量 SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE ...一般情況下 Hibernate 會(huì)把所有的字段都選出來。比如說有一個(gè)上面表有 8 個(gè)字段，其中有一兩個(gè)比較大的字段，varchar（255）/text。上面的場(chǎng)景中我為什么要把他們也選出來呢？用hibernate 的話，你又不能把這兩個(gè)不需要的字段設(shè)置為 lazy load，因?yàn)檫€有很多地方需要一次把整個(gè) domain object 加載出來。這個(gè)時(shí)候就能顯現(xiàn)出iBATIS 的好處了。如果我需要更新一條記錄（一個(gè)對(duì)象），如果使用 hibernate，需要現(xiàn)把對(duì)象 select 出來，然后再做 update。這對(duì)數(shù)據(jù)庫來說就是兩條 sql。而 iBATIS 只需要一條 update 的 sql 就可以了。減少一次與數(shù)據(jù)庫的交互，對(duì)于性能的提升是非常重要。3. 開發(fā)方面：開發(fā)效率上，我覺得兩者應(yīng)該差不多?？删S護(hù)性方面，我覺得 iBATIS 更好一些。因?yàn)?iBATIS 的 sql 都保存到單獨(dú)的文件中。而 Hibernate 在有些情況下可能會(huì)在 java 代碼中保 sql/hql。相對(duì) Hibernate“O/R”而言，iBATIS 是一種 “Sql Mapping”的 ORM 實(shí)現(xiàn)。 而 iBATIS 的著力點(diǎn)，則在于POJO 與 SQL 之間的映射關(guān)系。也就是說，iBATIS 并不會(huì)為程序員在運(yùn)行期自14動(dòng)生成 SQL 執(zhí)行。具體的 SQL 需要程序員編寫，然后通過映射配置文件，將SQL 所需的參數(shù)，以及返回的結(jié)果字段映射到指定 POJO。使用 iBATIS 提供的ORM 機(jī)制，對(duì)業(yè)務(wù)邏輯實(shí)現(xiàn)人員而言，面對(duì)的是純粹的 Java 對(duì)象，這一層與通過 Hibernate 實(shí)現(xiàn) ORM 而言基本一致，而對(duì)于具體的數(shù)據(jù)