第一章 Java Web應用開發技術

Java Web應用開發是基於JavaEE(JavaEnterprise Edition)框架的，而JavaEE是創建在Java平臺上的企業級應用解決方案。JavaEES框架提供的Web開發技術主要支持兩類軟件的開發和應用，一類是作高級信息系統框架的Web應用服務器(Web Application Server),另外一類是在Web服務器上運行的Web應用(Web Application).咱們之後所說的Java Web應用開發就是這裏的第二類.即在Web服務器上運行的Web應用開發.

WEB服務器、應用程序服務器區別

通俗的講，Web服務器傳送(serves)頁面使瀏覽器可以瀏覽，然而應用程序服務器提供的是客戶端應用程序能夠調用(call)的方法(methods)。確切一點，你能夠 說:Web服務器專門處理HTTP請求(request)，可是應用程序服務器是經過不少協議來爲應用程序提供(serves)商業邏輯 (business logic)。

Web服務器，能夠解析(handles)HTTP協議。當Web服務器接收到一個HTTP請求(request)，會返回一個HTTP響應 (response)，例如送回一個HTML頁面。爲了處理一個請求(request)，Web服務器能夠響應(response)一個靜態頁面或圖片， 進行頁面跳轉(redirect)，或者把動態響應(dynamic response)的產生委託(delegate)給一些其它的程序例如CGI腳本，JSP(JavaServer Pages)腳本，servlets，ASP(Active Server Pages)腳本，服務器端(server-side)JavaScript，或者一些其它的服務器端(server-side)技術。不管它們的目的如何，這些服務器端(server-side)的程序一般產生一個HTML的響應(response)來讓瀏覽器能夠瀏覽。

應用程序服務器，它經過各類協議，能夠包括HTTP，把商業邏輯暴露給(expose)客戶端應用程序。Web服務器主要是處理向瀏覽器發送HTML以供瀏覽，而應用程序服務器提供訪問商業邏輯的途徑以供客戶端應用程序使用。應用程序使用此商業邏輯就象你調用對象的一個方法 (或過程語言中的一個函數)同樣。

以這樣的定義，IIS、Apache、Tomcat均可以屬於Web服務器，Weblogic、WebSphere都屬於應用服務器。

Apache:在Web服務器中，Apache是純粹的Web服務器，常常與Tomcat配對使用。它對HTML頁面具備強大的解釋能力，可是不能解釋嵌入頁面內的服務器端腳本代碼（JSP/Servlet)

Tomcat:早期的Tomcat是一個嵌入Apache內的JSP/Servlet解釋引擎Apache+Tomcat就至關於IIS+ASP。後來的 Tomcat已再也不嵌入Apache內，Tomcat進程獨立於Apache進程運行。 並且，Tomcat已是一個獨立的Servlet和JSP容器，業務邏輯層代碼和界面交互層代碼能夠分離了。所以，有人把Tomcat叫作輕量級應用服 務器。

IIS:微軟早期的IIS，就是一個純粹的Web服務器。後來，它嵌入了ASP引擎，能夠解釋VBScript和JScript服務器端代碼了，這時，它 就能夠兼做應用服務器。固然，它與J2EE應用服務器根本沒法相比，可是，從功能上說，從原理上說，它勉強能夠稱之爲應用服務器。確切地說，它是兼有一點 應用服務器功能的Web服務器。

綜上：Apache是純粹的web服務器，而Tomcat和IIS由於具備瞭解釋執行服務器端代碼的能力，能夠稱做爲輕量級應用服務器或帶有服務器功能的Web服務器。

JavaEE框架的容器和組件

容器:指的是提供特定程序組件服務的標準化運行環境,經過這些組件能夠在JavaEE平臺上獲得所指望的服務.容器的做用是爲組件提供多種系統級服務.例如:生命週期管理、事務管理、數據緩存、異常處理實例池、線程以及安全性。

1. EJB容器——爲Enterprise JavaBean組件提供運行時環境,它對應於業務層和數據訪問層,主要負責數據處理以及和數據庫或其餘Java程序的通訊.
2. Web容器——管理JSP和Servlet等Web組件的運行,主要負責Web應用和瀏覽器的通訊,它對應於表示層.
3. 應用客戶端容器——負責Web應用在客戶端組件的運行,對應於用戶界面層.
4. Applet容器——負責在Web瀏覽器和Java插件（Java Plug-in）上運行Java Applet程序，對應於用戶界面層.

組件:是指在應用程序中能發揮特定功能的軟件單位,實質上是幾種特定的Java程序只不過這些程序被規定了固定的格式和編寫方法,它們的功能和使用方法在必定程度上被標準化了.

1. 客戶端組件——客戶端的Applet和客戶端應用程序.
2. Web組件——Web容器內的JSP、Servlet、Web過濾器、Web時間監聽器等。
3. EJB組件——EJB容器內的EJB組件.
   

 　　實質:組件是組裝到JavaEE平臺中獨立的軟件功能單元,每個JavaEE組件在容器中執行,容器爲組件提供標準服務和API.

Java架構的兩層、三層（三層架構、MVC)與四層

將系統的整個業務分層，這樣有利於系統的開發、維護、部署和擴展。分層是爲了實現「高內聚，低耦合」。採用「分而治之」的思想，把問題劃分開來各個解決，易於控制，延展和分配資源。

　　兩層架構：客戶端與數據庫

              

優勢：開發容易，結構簡單，易於理解

缺點：當任何一個地方發生變化時，都須要從新開發整個系統。「多層」放在一層，分工不明確耦合度高——難以適應需求變化，可維護性低、可擴展性低

三層架構：三層架構(3-tier architecture) 一般意義上的三層架構就是將整個業務應用劃分爲：界面層（User Interface layer）、業務邏輯層（Business Logic Layer）、數據訪問層（Data access layer）。區分層次的目的即爲了「高內聚低耦合」的思想。在軟件體系架構設計中，分層式結構是最多見，也是最重要的一種結構。微軟推薦的分層式結構通常分爲三層，從下至上分別爲：數據訪問層、業務邏輯層（又或稱爲領域層）、表示層。

               

優點：

一、結構清晰、耦合度低,

二、可維護性高，可擴展性高；

三、利於開發任務同步進行；容易適應需求變化

劣勢：

一、下降了系統的性能。這是不言而喻的。若是不採用分層式結構，不少業務能夠直接造訪數據庫，以此獲取相應的數據，現在卻必須經過中間層來完成。

二、有時會致使級聯的修改。這種修改尤爲體如今自上而下的方向。若是在表示層中須要增長一個功能，爲保證其設計符合分層式結構，可能須要在相應的業務邏輯層和數據訪問層中都增長相應的代碼

三、增長了代碼量，增長了工做量

界面層：

主要表示WEB方式，也能夠表示成WINFORM方式，WEB方式也能夠表現成：aspx，若是邏輯層至關強大和完善，不管表現層如何定義和更改，邏輯層都能完善地提供服務。主要對用戶的請求接受，以及數據的返回，爲客戶端提供應用程序的訪問。位於最外層（最上層），最接近用戶。用於顯示數據和接收用戶輸入的數據，爲用戶提供一種交互式操做的界面。

業務邏輯層：

主要是針對具體的問題的操做，也能夠理解成對數據層的操做，對數據業務邏輯處理，若是說數據層是積木，那邏輯層就是對這些積木的搭建。主要負責對數據層的操做。也就是說把一些數據層的操做進行組合。

數據訪問層：

主要是對非原始數據（數據庫或者文本文件等存放數據的形式）的操做層，而不是指原始數據，也就是說，是對數據庫的操做，而不是數據，具體爲業務邏輯層或表示層提供數據服務．主要看數據層裏面有沒有包含邏輯處理，實際上它的各個函數主要完成各個對數據文件的操做。而沒必要管其餘操做。有時候也稱爲是持久層，其功能主要是負責數據庫的訪問，能夠訪問數據庫系統、二進制文件、文本文檔或是XML文檔。

MVC:是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設計典範，用一種業務邏輯、數據、界面顯示分離的方法組織代碼，將業務邏輯彙集到一個部件裏面，在改進和個性化定製界面及用戶交互的同時，不須要從新編寫業務邏輯。MVC被獨特的發展起來用於映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。

　　View（視圖）是應用程序中處理數據顯示的部分。一般視圖是依據模型數據建立的。

Controller（控制器）是應用程序中處理用戶交互的部分。一般控制器負責從視圖讀取數據，控制用戶輸入，並向模型發送數據。就是將用戶請求轉發給模型層，通過處理後把結果返回到界面展示的一箇中間層

Model（模型）是應用程序中用於處理應用程序數據邏輯的部分。一般模型對象負責在數據庫中存取數據。

 

　　三層架構中數據訪問層只負責數據庫的CRUD，不負責業務；MVC中Controller只負責任務的轉發，不負責業務；三層架構和MVC的區別在於後兩層

　　四層：DAO層、Service層、Controller層與View層

DAO層：DAO層主要是作數據持久層的工做，負責與數據庫進行聯絡的一些任務都封裝在此，DAO層的設計首先是設計DAO的接口，而後在Spring的配置文件中定義此接口的實現類，而後就可在模塊中調用此接口來進行數據業務的處理，而不用關心此接口的具體實現類是哪一個類，顯得結構很是清晰，DAO層的數據源配置，以及有關數據庫鏈接的參數都在Spring的配置文件中進行配置。

Service層：Service層主要負責業務模塊的邏輯應用設計。一樣是首先設計接口，再設計其實現的類，接着再Spring的配置文件中配置其實現的關聯。這樣咱們就能夠在應用中調用Service接口來進行業務處理。Service層的業務實現，具體要調用到已定義的DAO層的接口，封裝Service層的業務邏輯有利於通用的業務邏輯的獨立性和重複利用性，程序顯得很是簡潔。

Controller層：Controller層負責具體的業務模塊流程的控制，在此層裏面要調用Serice層的接口來控制業務流程，控制的配置也一樣是在Spring的配置文件裏面進行，針對具體的業務流程，會有不一樣的控制器，咱們具體的設計過程當中能夠將流程進行抽象概括，設計出能夠重複利用的子單元流程模塊，這樣不只使程序結構變得清晰，也大大減小了代碼量。

View層： 此層與控制層結合比較緊密，須要兩者結合起來協同工發。View層主要負責前臺jsp頁面的表示。

　　拓展：

1. DAO層，Service層這兩個層次均可以單獨開發，互相的耦合度很低，徹底能夠獨立進行，這樣的一種模式在開發大項目的過程當中尤爲有優點，Controller，View層由於耦合度比較高，於是要結合在一塊兒開發，可是也能夠看做一個總體獨立於前兩個層進行開發。這樣，在層與層以前咱們只須要知道接口的定義，調用接口便可完成所須要的邏輯單元應用，一切顯得很是清晰簡單。   
2. DAO設計的整體規劃須要和設計的表，和實現類之間一一對應。  
3. DAO層所定義的接口裏的方法都大同小異，這是由咱們在DAO層對數據庫訪問的操做來決定的，對數據庫的操做，咱們基本要用到的就是新增，更新，刪除，查詢等方法。於是DAO層裏面基本上都應該要涵蓋這些方法對應的操做。除此以外，能夠定義一些自定義的特殊的對數據庫訪問的方法。   Service邏輯層設計  
4. Service層是創建在DAO層之上的，創建了DAO層後才能夠創建Service層，而Service層又是在Controller層之下的，於是Service層應該既調用DAO層的接口，又要提供接口給Controller層的類來進行調用，它恰好處於一箇中間層的位置。每一個模型都有一個Service接口，每一個接口分別封裝各自的業務處理方法。
5. 在DAO層定義的一些方法，在Service層並無使用，那爲何還要在DAO層進行定義呢？這是由咱們定義的需求邏輯所決定的。DAO層的操做 通過抽象後基本上都是通用的，於是咱們在定義DAO層的時候能夠將相關的方法定義完畢，這樣的好處是在對Service進行擴展的時候不須要再對DAO層進行修改，提升了程序的可擴展性。