JSP開發模式
jsp開發模式的發展
1.模式1：（適合小型項目的技術的開發）
a.第一版本，純jsp（封裝數據，處理數據，顯示數據）
b.第二版本，Jsp+JavaBean.
jsp:收集數據，顯示數據
JavaBean：封裝、處理
2.模式2：servlet+Jsp+JavaBean（是mvc在java中的具體的實現，是java技術實現的具體的內容）
a.servlet:負責協調jsp和javabean，獲得數據，處理數據（業務邏輯），封裝到javabean中，選擇jsp去顯示數據。
b.jsp:顯示
c.JavaBean:封裝和簡單處理
思想：業務處理與顯示數據相分離。
軟件設計模式
1.MVC軟件設計模式（和java無關）
是一種分離業務邏輯和顯示界面的設計方法。
M:model模型
V:view視圖
C:Controller控制器
2.對於javaweb開發的mvc模式：
servlet(controller)+jsp(view)+javabean(model)
那麼經典的三冊架構的體系圖如下：
servlet(controller)+jsp(view)+javabean(model)
那麼經典的三冊架構的體系圖如下：
達到這種經典的三層架構以後，javaweb的架構已經很不錯了，但是從軟件工程角度分析，上述架構還是存在問題。
那麼看一下上述架構的使用。
在中心的黃色部分：也就是服務端部分，層與層之間的調用關係。
舉一個例子：
web層：UserServlet.java類
service層：UserService類
dao層：UserDao類
javaBean：user
那麼層與層之間的調用關係就該是這樣：
在UserServlet.java中調用UserService。
那麼調用的方式只能是在UserServlet類中去創建UserService的對象。
如下：
class UserServlet{
UserServcie userService=new UserService（）；
//調用userService的相關方法進行業務邏輯的操作
。。。。
}
同理：UserService調用UserDao的時候，也有類似上述的代碼。
有上述的分析得出結論1：
1.那麼上述代碼之間的層與層之間的關係就很緊密。
是違背了軟件工程的設計思想的。
軟件工程要求，模塊與模塊之間的耦合式越低越好。一句經典的軟件工程設計的話是這樣的。
“高內聚，低耦合”。
同時上述的dao層，我們看一下既有對xml的操作，也有對db的操作，甚至還有更多。得出了結論2：
2.上述架構，同時違背了“高內聚，低耦合”中的高內聚的思想。
於是上面的架構體系又有了如下的增進：
那麼看一下上述架構的使用。
在中心的黃色部分：也就是服務端部分，層與層之間的調用關係。
舉一個例子：
web層：UserServlet.java類
service層：UserService類
dao層：UserDao類
javaBean：user
那麼層與層之間的調用關係就該是這樣：
在UserServlet.java中調用UserService。
那麼調用的方式只能是在UserServlet類中去創建UserService的對象。
如下：
class UserServlet{
UserServcie userService=new UserService（）；
//調用userService的相關方法進行業務邏輯的操作
。。。。
}
同理：UserService調用UserDao的時候，也有類似上述的代碼。
有上述的分析得出結論1：
1.那麼上述代碼之間的層與層之間的關係就很緊密。
是違背了軟件工程的設計思想的。
軟件工程要求，模塊與模塊之間的耦合式越低越好。一句經典的軟件工程設計的話是這樣的。
“高內聚，低耦合”。
同時上述的dao層，我們看一下既有對xml的操作，也有對db的操作，甚至還有更多。得出了結論2：
2.上述架構，同時違背了“高內聚，低耦合”中的高內聚的思想。
於是上面的架構體系又有了如下的增進：
看service層，dao層
1.解決dao層的內聚問題，把xmlDao和dbDao進行分離。
2.對dao層抽取一個共性的接口出來。Dao接口
分析：之前的架構中，service層調用dao層是這樣的。
UserService中需要寫這樣的代碼：XmlDao xmlDao=new XmlDao（）//此時沒有接口
加上接口以後，Dao dao=new XmlDao();
3.添加工廠
上面的寫法變成：Dao dao=Factory.getXmlDao();
那麼工廠如何調用dao層的相關方法呢？如果直接調用，出現的結果是雖然解決了service層和dao層之間的耦合關係，但是其實只不過演變
成了工廠和dao層之間的高耦合。
那麼加入了xml技術，工廠通過讀取xml文件，然後利用java的反射，去創建所需創建的對象就ok了。
而在xml中只要提供了類的全路徑，然後做相關配置，目的是方便工廠去讀取xml文件去創建對象。
4.添加配置文件。
配置文件僅僅是字符串，和dao層之間沒有耦合關係。
總結：對於第三種架構（高內聚，低耦合），便於維護，便於擴展。
爲什麼便於擴展，舉個例子：比如，dao層中，又有了新的持久化技術，service層實際上無所知道不知道，只要修改配置文件。工廠就會去有
相應的操作。這樣一來，是不是便於維護和擴展。
上面了，我們看了service層，dao層，通過接口，工廠類，配置文件的方式實現瞭解耦。
同理，web層，service層也可以通過相同的方式的進行解耦。在上圖中沒有完全體現。
隨着技術的發展，出現了很多mvc的框架比如struts+spring+hibernate/springMvc.
在剛出現這些框架的時候，基本上都是通過上述方式進行解耦。用過框架的人都知道，框架多基於配置文件，反射原理，內省等。
再發展瞭如今，搞架構的那些人，覺得，寫配置文件也很費勁，就有了如今的基於註解模式的框架設計。
但是，上述的架構思想，和演變過程，是後期框架技術的源頭哦。
後期，我也會對JavaWeb項目開發過程的框架技術結合MVC設計模式做更深入的分析。通常javaweb+框架技術的開發，被人們稱
作java企業級開發。也就比較的流行的J2EE/JAVAEE.
補充：在javaweb項目的基於MVC軟件設計模式，一般會進行如下分包結構：
使用分包描述結構
com.ghsy ,公司域名倒寫(安徽安慶高恆塑業有限責任公司)
com.ghsy.項目名稱
com.ghsy.項目名稱.dao dao接口
com.ghsy.項目名稱.dao.impl dao實現類
com.ghsy.項目名稱.service service接口
com.ghsy.項目名稱.service.impl service實現類
com.ghsy.項目名稱.web.servlet servlet處理類
com.ghsy.項目名稱.web.filter 過濾器處理類
com.ghsy.項目名稱.web.listener 監聽器處理類
com.ghsy.項目名稱.domain javabean 封裝數據（bean）
com.ghsy.項目名稱.utils 工具類
com.ghsy.項目名稱.exception 自定義異常
com.ghsy.項目名稱.constant java常量 Xxx.NAME
/WEB-INF/ jsp頁面，安全
* 使用請求轉發顯示jsp頁面