爲解決一個開放性問題而設計的具備必定約束性的支撐結構,再次結構上能夠根據具體問題擴展,安插更多的組成部分,從而更迅速和方便地構建完整解決問題的方案。前端
用一種業務邏輯、數據、界面顯示分離的方法組織代碼,將業務邏輯彙集到一個部件裏面,在改進和個性化定製界面及用戶交互的同時,不須要從新編寫業務邏輯。web
最簡單的:JSp(View)+Servlet(Controller)+JavaBean(model)編程
工做流程:瀏覽器
(1)控制器收到來自用戶的請求app
(2)控制器調用Javabean完成業務框架
(3)完成業務後經過控制器跳轉Jsp頁面的方式給用戶反饋信息模塊化
(4)Jsp給用戶作出響應學習
是爲了解決傳統MVC模式問題而出現的框架。ui
傳統MVC模式問題:(1)全部servlet和servlet映射都要配置在web.xml中,若是項目過大,web.xml就太龐大了,而且不能實現模塊化管理。編碼
(2)servlet主要功能是接收參數,調用邏輯,跳轉界面,而像字符編碼,文件上傳等功能也要寫在servlet中,不能讓servlet完成他的主要功能,而須要作處理一些 特例。
(3)接收參數麻煩,不能同經過model接收,只能單個接收,接收完成後轉換封裝model
(4)跳轉頁面方式單一,且當頁面名稱發生改變時須要修改servlet源碼。
經常使用MVC框架:Structs二、SpringMVC
攔截------>判斷------->尋找-------->執行-------->響應
(1)客戶端瀏覽器發送請求
(2)這個請求通過一系列過濾器後到達核心過濾器
(3)核心過濾器經過ActionMapper判斷當前的請求是否須要某個Action處理,若是不須要,則走原來的流程,若是須要則把求情交給ActionProxy來處理
(4)ActionProxy經過ConfiguratonManager詢問框架的配置文件(structs.xml),找到須要調用的Action類
(5)建立一個ActionInvocation實例,來調用Action的對應方法,獲取結果集的name,在調用先後都會執行相關攔截器
(6)經過結果集的name知道對應的結果集來對瀏覽器進行響應
經過動態配置方式,能夠在執行Action的方法先後加入相干邏輯完成任務。
使用場景:(1)用戶登陸判斷,在執行Action以前判斷用戶是否登錄,若是沒有登錄則跳轉到登錄頁面
(2)用戶權限判斷
(3)操做日誌
Structs2的功能(參數處理,文件上傳,字符編碼等)都是經過系統攔截器實現的,也能夠自定義攔截器,進行可插拔配置。
(1)用戶發送請求,請求被Spring前端控制捕獲
(2)解析請求獲得URL,調用HandllerMapping得到該Handler配置的相關對象
(3)根據得到的Handler,選擇額一個合適的HandlerAdapter,填充Handler入參,執行Handler,完成後向servlet返回一個ModelAndView
(4)Servlet選擇合適的ViewResolver
(5)渲染視圖,servlet將渲染結果返回給客戶端
(1)核心控制器不一樣,SpringMVC——servlet,Structs2——Filter
(2)控制器實例:SpringMVC是基於方法的設計,更像servlet,只有一個實例,每次請求執行對應方法便可;Structs2是基於對象
(3)管理方式不一樣:如今不少企業採用Spring的管理方式,而SpringMVC是Spring中的一個模塊,因此Spring對於SpringMVC的控制器管理更加簡單方便
(4)參數傳遞不一樣:Structs2中自身提供多種參數接收,都是經過valueStack進行傳遞和賦值,而SpringMVC是同故宮方法的參數進行接收。
(5)學習難度:Spring更簡單
(6)攔截器的實現機制不一樣:Structs2有本身的interceptor機制,而SpringMVC用的是獨立的AOP方式。
(7)SpringMVC處理Ajax請求直接返回數據,Structs2是經過插件的方式進行處理。
Spring是J2EE應用程序框架,是輕量級的IOC和AOP的容器框架。
(1)IOC:Inversion of Control(控制權反轉)
例如:原來個人service須要調用dao,service就須要建立dao,使用Spring後當SPringle發現service依賴於dao的時候,就給我注入(依賴注入)
(2)AOP:面向切面編程
核心原理:使用動態代理的方式在執行先後或初夏異常後加入相關邏輯
主要用來作:事務處理、權限判斷、操做日誌。。。
即多個事務存在時怎麼處理的策略。
Required(須要)——若是存在一個事務,則支持當前事務,若是沒有事務則開啓事務
Supports(支持)——若是存在一個事務,則支持當前事務,若是沒有則進行非事務的執行
Mandatory(必要/必須)——若是存在一個事務,則支持當前事務,若是沒有事務則拋出異常
Required_new——老是開啓一個新事務,若是一個事務已經存在,則將這個事務掛起
Not_support——老是非事務的執行,並掛起任何存在的事務
Never——老是非事務的執行,並掛起任何存在的事務,若是存在一個活動事務,則拋出異常
Nested(嵌套)——若是有就嵌套,沒有就開啓事務。