最近在中軟學習ssm框架的知識在這裏總結一下！
以前開發BS架構的web項目時，像筆者這種菜鳥就是用html，js，css，ajax寫前臺，servlet作爲後臺接收請求，再用jdbc操作數據庫。用這樣的方式實現
1.前臺發送請求------>2.後臺servlet接收請求------->3.在servlet裏獲取請求的參數------>4.通過參數我們進行相應的數據庫操作------->5.將處理好的數據再通過servlet響應給前臺
就這樣我們就實現了請求響應的一個流程。
這種方式簡單但效率低，對於每一個操作我們都需要些個servlet去接收和響應。對於每一個對象我們都需要些很多重複的增刪改查的方法。正因爲有這樣的缺陷大佬們才發明了框架。然而你不管你外面包裝了多少層我們的底層的實現還是用上述的方式，只不過包裝後更簡單了。
1.先講講servlet和springmvc：
SSM（Spring+SpringMVC+MyBatis）其中一個S指的就是springmvc。在springmvc裏他有一個核心的servlet用於接收所有的請求org.springframework.web.servlet.DispatcherServlet。而用servlet我們每一個請求都要寫一個servlet。
在DispatcherServlet裏面我們獲取請求的
URI（URI一般由三部分組成：一、主機名。二、標誌符三、相對URI
下面是一個圖像的相對URI：
<IMG src="../icons/logo.gif" alt="logo">
而在程序裏獲取的就是類似於 項目名/目錄/../savedept.do
)
我們通過uri來判斷我們請求的信息然後具體的操作我們調用不同的
控制器controller（
@RequestMapping(value="/savedept.do")
@ResponseBody
public String savedata(){
//調用服務中的方法
departmentService.Savedata();
System.out.println("11111");
return "ok";
}
）
然後將處理好的結果通過DispatcherServlet響應回去或者響應相應的視圖（前臺網頁）。
2.講講JDBC和mybatis
用JDBC的話我們一般是這幾步：
1.根據我們的數據庫信息創建一個連接對象；
2.寫增刪改查操作函數，在這裏會有preparedStatement，statement這兩種；
3.就是在響應的servlet裏調用；
用mybatis這是如下步驟：
1.對於我們數據庫中每一個表我們會有一個響應的javabean類；
2.對於沒有個javabean我們會寫一個對應的接口；
3.對於每一個接口我們相應的會配置一個mapper配置文件，用於標註我們接口方法具體的數據庫操作
4.具體實現我們的接口方法
（
SqlSessionFactoryBuilder通過mybatis-config.xml創建sqlSessionFactory；
再通過sqlSessionFactory.openSession()獲取sqlsesion；
sqlsesion獲取mapper.xml配置信息創建接口；
調用接口方法；
關閉sqlsession
）；
3.通過new實例化對象和spring控制反轉
Ioc—Inversion of Control，即“控制反轉”，不是什麼技術，而是一種設計思想。在Java開發中，Ioc意味着將你設計好的對象交給容器控制，而不是傳統的在你的對象內部直接控制。如何理解好Ioc呢？理解好Ioc的關鍵是要明確“誰控制誰，控制什麼，爲何是反轉（有反轉就應該有正轉了），哪些方面反轉了”，那我們來深入分析一下：
●誰控制誰，控制什麼：傳統Java SE程序設計，我們直接在對象內部通過new進行創建對象，是程序主動去創建依賴對象；而IoC是有專門一個容器來創建這些對象，即由Ioc容器來控制對象的創建；誰控制誰？當然是IoC 容器控制了對象；控制什麼？那就是主要控制了外部資源獲取（不只是對象包括比如文件等）。
●爲何是反轉，哪些方面反轉了：有反轉就有正轉，傳統應用程序是由我們自己在對象中主動控制去直接獲取依賴對象，也就是正轉；而反轉則是由容器來幫忙創建及注入依賴對象；爲何是反轉？因爲由容器幫我們查找及注入依賴對象，對象只是被動的接受依賴對象，所以是反轉；哪些方面反轉了？依賴對象的獲取被反轉了。
用圖例說明一下，傳統程序設計如圖2-1，都是主動去創建相關對象然後再組合起來：
圖2-1 傳統應用程序示意圖
當有了IoC/DI的容器後，在客戶端類中不再主動去創建這些對象了，如圖2-2所示:
圖2-2有IoC/DI容器後程序結構示意圖
本文參考了http://jinnianshilongnian.iteye.com/blog/1413846