JAVA-WEB

#1、MVC設計模式 所謂MVC，即Model-View-Controller

1）Model層：Model指模型部分，應用對象；通常在應用中Model層包括業務處理層和數據訪問層。數據訪問層主要是對數據庫的一些操做的封裝。業務處理層應用JavaBean構建， JavaBean主要是用做將從View層獲取的數據和數據庫的數據進行橋接。模型表示企業數據和業務規則。在MVC的三個部件中，模型擁有最多的處理任務。模型與數據格式無關，這樣一個模型能爲多個視圖提供數據。因爲應用於模型的代碼只需寫一次就能夠被多個視圖重用，因此減小了代碼的重複性。

2）Controller層：Controller指控制器部分，邏輯處理、控制實體數據在視圖上展現、調用模型處理業務請求；通常是對View層提交的請求爲其設置對應的Servlet進行特定功能的處理，接受用戶的輸入並調用模型和視圖去完成用戶的需求。Controller通常只是在Web應用中充當一箇中介者的做用。

3）View層：View指視圖部分，數據的展示；這一部分的內容是展現給用戶實際進行交互的，一般使用JSP和HTML進行構建。

在 MVC 模式中，Web 用戶向服務器提交的全部請求都由控制器接管。接受到請求以後，控制器負責決定應該調用哪一個模型來進行處理；而後模型根據用戶請求進行相應的業務邏輯處理，並返回數據；最後控制器調用相應的視圖來格式化模型返回的數據，並經過視圖呈現給用戶。

優勢：

• 低耦合性
  視圖層和業務層分離，這樣就容許更改視圖層代碼而不用從新編譯模型和控制器代碼
• 高重用性和可適用性
  改變視圖層的實現方式，而控制層和模型層無需作任何改變
• 較低的生命週期成本
  MVC使開發和維護用戶接口的技術含量下降
• 快速的部署
• 可維護性
  分離視圖層和業務邏輯層也使得WEB應用更易於維護和修改
• 模型的可移植性
  模型是獨立於視圖的，因此能夠把一個模型獨立地移植到新的平臺工做。須要作的只是在新平臺上對視圖和控制器進行新的修改
• 有利於軟件工程化管理
  因爲不一樣的層各司其職，每一層不一樣的應用具備某些相同的特徵，有利於經過工程化、工具化管理程序代碼
• 潛在的框架結構
  能夠基於此模型創建應用程序框架，不只僅是用在設計界面的設計中

缺點：

• 增長了系統結構和實現的複雜性
  對於簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增長結構的複雜性，並可能產生過多的更新操做，下降運行效率；
• 視圖與控制器間的過於緊密的鏈接
  視圖與控制器是相互分離，但確實聯繫緊密的部件，視圖沒有控制器的存在，其應用是頗有限的，反之亦然，這樣就妨礙了他們的獨立重用；
• 視圖對模型數據的低效率訪問
  依據模型操做接口的不一樣，視圖可能須要屢次調用才能得到足夠的顯示數據。對未變化數據的沒必要要的頻繁訪問，也將損害操做性能；

MVC屬於架構/框架設計模式，即觀察者模式，策略模式，組合模式等JAVA面向對象設計模式的組裝； 框架（Framework）是一組協同工做的類，它們爲特定類型的軟件構築了一個可重用的設計

框架的特性：

• 在應用方面，框架是整個或部分系統的可重用設計，表現爲一組抽象構件及構件實例間交互的方法；在目標方面，框架是可被應用開發者定製的應用骨架；
• 框架是一種軟件，是應用程序的半成品。它能夠供系統開發者選用，以完成系統的開發；
• 框架解決的是某個特定範圍即領域的問題。每一個框架都有本身的目標領域，它並不能知足全部人的全部需求；

#2、MVC框架 1）jsp+servlet+javabean：適用於比較小的項目

2）struts1，webWork(xwork1 ，webWork2)，dwr3

3）struts2
工做原理圖：

參考文獻：http://blog.csdn.net/laner0515/article/details/27692673/

4）springMVC 工做原理圖：

參考文獻：http://blog.csdn.net/zuoluoboy/article/details/19766131

對比

1）struts1和struts2

• struts2=struts1+webwork2
• Struts1的一個廣泛問題是使用抽象類編程而不是接口，而struts2的Action是接口
• Struts1 Action是單例模式，Struts2 Action對象爲每個請求產生一個實例，所以沒有線程安全問題
• Struts1 Action 依賴於Servlet API，Struts 2 Action不依賴於容器，容許Action脫離容器單獨被測試
• Struts2 在請求對象捕獲輸入/綁定，表達式語言上，校驗等方面要優於Struts1

2）struts2和springMVC
參考文獻：
http://blog.csdn.net/gstormspire/article/details/8239182
http://blog.csdn.net/chenleixing/article/details/44570681

#3、RESTFUL REST 是一種思惟方式，而非協議或標準。它是設計基於命名資源而非消息的鬆耦合應用程序 — 一般指面向 Web 的應用程序 — 的一種風格；

REST 「強調組件交互的可伸縮性、界面的廣泛性、獨立部署組件以及使用中間組件來減小交互延遲，加強安全性並封裝遺留系統」。RESTful構建的系統具備高度的可伸縮性，同時與底層數據鬆散耦合；並且能夠很好地利用緩存；

若是開發者在開發過程當中能堅持 REST 原則，將能夠獲得一個使用了優質 Web 架構的系統，從而爲系統提供更好的可伸縮性，並下降開發難度。關於 REST 架構的主要原則以下：

• 網絡上的全部事物均可被抽象爲資源（Resource）。
• 每一個資源都有一個惟一的資源標識符（Resource Identifier）。
• 同一資源具備多種表現形式。
• 使用標準方法操做資源。
• 經過緩存來提升性能。
• 對資源的各類操做不會改變資源標識符。
• 全部的操做都是無狀態的（Stateless）。

參考文獻：http://www.ibm.com/developerworks/cn/java/j-lo-struts2rest/

springboot
play framework
webwork