1.什麼是事務控制？
答：事務控制就是將一系列操作當成一個不可拆分的邏輯單元，保證這些操作要麼都成功，要麼都失敗。在關係資料庫中，一個事務可以是一條SQL語句，一組SQL語句或整個程式。
事務是恢復和併發控制的基本單位。
事務應該具有4個屬性：原子性、一致性、隔離性、持續性。這四個屬性通常稱為ACID特性。
原子性（atomicity）。一個事務是一個不可分割的工作單位，事務中包括的諸操作要麼都做，要麼都不做。
一致性（consistency）。事務必須是使資料庫從一個一致性狀態變到另一個一致性狀態。一致性與原子性是密切相關的。
隔離性（isolation）。一個事務的執行不能被其他事務干擾。即一個事務內部的操作及使用的資料對併發的其他事務是隔離的，併發執行的各個事務之間不能互相干擾。
永續性（durability）。持續性也稱永久性（permanence），指一個事務一旦提交，它對資料庫中資料的改變就應該是永久性的。接下來的其他操作或故障不應該對其有任何影響。
事務有兩種操作：提交，回滾

2.過濾器的作用？
過 濾器是一個物件，可以傳輸請求或修改響應。它可以在請求到達Servlet/JSP之前對其進行預處理，而且能夠在響應離開Servlet/JSP之後對 其進行後處理。所以如果你有幾個Servlet/JSP需要執行同樣的資料轉換或頁面處理的話，你就可以寫一個過濾器類，然後在部署描述檔案 （web.xml）中把該過濾器與對應的Servlet/JSP聯絡起來。你可以一個過濾器以作用於一個或一組servlet，零個或多個過濾器能過濾一 個或多個servlet。一個過濾器實現java.servlet.Filter介面並定義它的三個方法：1． void init(FilterConfig config) throws ServletException:在過濾器執行service前被呼叫，以設定過濾器的配置物件。2． void destroy();在過濾器執行service後被呼叫。3． Void doFilter(ServletRequest req,ServletResponse res,FilterChain chain) throws IOException,ServletException;

3.為什麼要引入連線池？
首先在Web開發中，如果使用 JDBC連線資料庫，那麼每次訪問請求都必須建立連線——開啟資料庫——存取資料庫——關閉連線等一系列步驟。但是我們知道資料庫的連線開啟不僅費時，而 且消耗比較多的系統資源。如果進行資料庫操作的次數比較少，那麼還不至於有多大的影響，但是假如頻繁的進行資料庫操作，那麼系統的效能將會受到很大影響。
其 次，是造成資料庫連線洩漏。資料庫連線洩漏這個詞是第一次聽說，指的是如果在某次使用或者某段程式中沒有正確地關閉Connection、 Statement和ResultSet資源，那麼每次執行都會留下一些沒有關閉的連線，這些連線失去了引用而不能得到重新使用，因此就造成了資料庫連線 的洩漏。資料庫連線的資源是寶貴而且是有限的，如果在某段使用頻率很高的程式碼中出現這種洩漏，那麼資料庫連線資源將被耗盡，影響系統的正常運轉。
為了解決上述問題，因此就引入了資料庫連線池技術。用一句話概括資料庫連線池技術那就是負責分配、管理和釋放資料庫連線。

4.JSP中動態INCLUDE與靜態INCLUDE的區別？
動態INCLUDE用jsp:include動作實現 它總是會檢查所含檔案中的變化，適合用於包含動態頁面，並且可以帶引數。
靜態INCLUDE用include偽碼實現,定不會檢查所含檔案的變化，適用於包含靜態頁面
<%@include file=””%> 編譯期 匯入 合併成1個Servlet 效率較高 (用include偽碼實現，適用於包含靜態頁面)
<jsp:include file=””> 動態連線 效率低於<%@include file=””%> (但它總是會檢查所含檔案中的變化，適合用於包含動態頁面，並且可以帶引數)
主要就是1個編譯期就合成1個Servlet了 一個是2個Servlet 動態連線
（JSP 最終就是被容器編譯成個 Servlet ）

5. jsp中，session物件存在哪個地方，如何進行存取，存在伺服器哪個地方，如何存的？
1、session在何時被建立
一 個常見的誤解是以為session在有客戶端訪問時就被建立，然而事實是直到某server端程式呼叫 HttpServletRequest.getSession(true)這樣的語句時才被建立，注意如果JSP沒有顯示的使用 <% @page session=”false”%> 關閉session，則JSP檔案在編譯成Servlet時將會自動加上這樣一條語句 HttpSession session = HttpServletRequest.getSession(true);這也是JSP中隱含的 session物件的來歷。
由於session會消耗記憶體資源，因此，如果不打算使用session，應該在所有的JSP中關閉它。
2、session何時被刪除
綜合前面的討論，session在下列情況下被刪除a.程式呼叫HttpSession.invalidate();或b.距離上一次收到客戶端傳送的session id時間間隔超過了session的超時設定;或c.伺服器程序被停止（非持久session）
3、如何做到在瀏覽器關閉時刪除session
嚴格的講，做不到這一點。可以做一點努力的辦法是在所有的客戶端頁面裡使用javascript程式碼window.oncolose來監視瀏覽器的關閉動作，然後向伺服器傳送一個請求來刪除session。但是對於瀏覽器崩潰或者強行殺死程序這些非常規手段仍然無能為力。
4、有個HttpSessionListener是怎麼回事
你 可以建立這樣的listener去監控session的建立和銷燬事件，使得在發生這樣的事件時你可以做一些相應的工作。注意是session的建立和銷 毀動作觸發listener，而不是相反。類似的與HttpSession有關的listener還有 HttpSessionBindingListener，HttpSessionActivationListener和 HttpSessionAttributeListener。
5、存放在session中的物件必須是可序列化的嗎
不是必需的。要求物件 可序列化只是為了session能夠在叢集中被複制或者能夠持久儲存或者在必要時server能夠暫時把session交換出記憶體。在 Weblogic Server的session中放置一個不可序列化的物件在控制檯上會收到一個警告。我所用過的某個iPlanet版本如果 session中有不可序列化的物件，在session銷燬時會有一個Exception，很奇怪。
6、如何才能正確的應付客戶端禁止cookie的可能性
對所有的URL使用URL重寫，包括超連結，form的action，和重定向的URL，具體做法參見

http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

7、開兩個瀏覽器視窗訪問應用程式會使用同一個session還是不同的session
參見第三小節對cookie的討論，對session來說是隻認id不認人，因此不同的瀏覽器，不同的視窗開啟方式以及不同的cookie儲存方式都會對這個問題的答案有影響。
8、如何防止使用者開啟兩個瀏覽器視窗操作導致的session混亂
這 個問題與防止表單多次提交是類似的，可以通過設定客戶端的令牌來解決。就是在伺服器每次生成一個不同的id返回給客戶端，同時儲存在session裡，客 戶端提交表單時必須把這個id也返回伺服器，程式首先比較返回的id與儲存在session裡的值是否一致，如果不一致則說明本次操作已經被提交過了。可 以參看《J2EE核心模式》關於表示層模式的部分。需要注意的是對於使用javascript window.open開啟的視窗，一般不設定這個id，或者使用單獨的id，以防主視窗無法操作，建議不要再window.open開啟的窗口裡做修改 操作，這樣就可以不用設定。
9、為什麼在Weblogic Server中改變session的值後要重新呼叫一次session.setValue
做這個動作主要是為了在叢集環境中提示Weblogic Server session中的值發生了改變，需要向其他伺服器程序複製新的session值。
10、為什麼session不見了
排 除session正常失效的因素之外，伺服器本身的可能性應該是微乎其微的，雖然筆者在iPlanet6SP1加若干補丁的Solaris版本上倒也遇到 過；瀏覽器外掛的可能性次之，筆者也遇到過3721外掛造成的問題；理論上防火牆或者代理伺服器在cookie處理上也有可能會出現問題。
出現這一問題的大部分原因都是程式的錯誤，最常見的就是在一個應用程式中去訪問另外一個應用程式。我們在下一節討論這個問題。

6.<%…%>和<%!…%>的區別？
<%…%>用於在JSP頁面中嵌入Java指令碼
<%!…%>用於在JSP頁面中申明變數或方法，可以在該頁面中的<%…%>指令碼中呼叫，宣告的變數相當於Servlet中的定義的成員變數

7.什麼是WEBSERVICE?及它的常用開發框架？
Web Service就是為了使原來各孤立的站點之間的資訊能夠相互通訊、共享而提出的一種介面。
Web Service所使用的是Internet上統一、開放的標準，如HTTP、XML、SOAP（簡單物件訪問協議）、WSDL等，所以Web Service可以在任何支援這些標準的環境（Windows,Linux）中使用。
優勢：(1).跨平臺。
(2).SOAP協議是基於XML和HTTP這些業界的標準的，得到了所有的重要公司的支援。
(3).由於使用了SOAP，資料是以ASCII文字的方式而非二進位制傳輸，除錯很方便；並且由於這樣，它的資料容易通過防火牆，不需要防火牆為了程式而單獨開一個“漏洞”。
(4).此外，WebService實現的技術難度要比CORBA和DCOM小得多。
(5).要實現B2B整合，EDI比較完善與比較複雜；而用WebService則可以低成本的實現，小公司也可以用上
(6).在C/S的程式中，WebService可以實現網頁無整體重新整理的與伺服器打交道並取數。
缺點：
(1).WebService使用了XML對資料封裝，會造成大量的資料要在網路中傳輸。
(2).WebService規範沒有規定任何與實現相關的細節，包括物件模型、程式語言，這一點，它不如CORBA
webservice的幾種常用框架及開發過程：
Net環境 IDE為Microsoft Visual Studio2005
Java環境 CXF CXF的前身是Xfire，具體內容可參照http://xfire.codehaus.org/ 。
IDE為Eclipse 3.2 （JDK 1.5以上）
NetBeans 由於Sun已經在J2EE5.0中提供了對Jax-ws規範的實現，並且提供了NetBeans IDE對J2EE5.0的支援，使得開發web service非常簡單。前提條件是我們需要到http://www.netbeans.org/ 下載NetBeans 6.0。官方的下載檔案中已經集成了Tomcat6.0和J2EE5.0。
Axis 比較
? 開發過程比較
1、NetBeans IDE基本可以與.Net的開發工具VS 2005相媲美，後者有內嵌的測試伺服器，前者也可以使用內嵌的glassfish。
2、CXF相對而言也比較簡單(依賴於與Spring的整合)，Axis要更復雜些，且難以掌握
? 效能比較
1、 CXF對於大資料量的處理，效能要優於NetBeans IDE開發的webservice；小資料量的處理兩者差不
2、 對於.Net開發的webservice的效能很難與Java環境下開發的webservice進行效能比較，由於應用伺服器不相同（前者依賴於IIS的支援）。
? 結論
考慮到服務的效能和現有應用的整合，使用CXF進行web service開發是比較適中的選擇。從簡單易用方面考慮，可以使用NetBeans進行上手入門。從與之前作的webservice的相容方面考慮，可以採用Axis，只有它還支援RPC的呼叫方式。

8.請具體說J2EE是怎樣分層的？
1.客戶端層(Client Tier) 客戶端層用來實現企業級應用系統的操作介面和顯示，另外，某些客戶端程式也可實現業務邏輯
可分為基於Web的和非基於Web的客戶端兩種情況
基於Web的情況下主要作為企業Web伺服器的瀏覽器
非基於Web的客戶層則是獨立的應用程式，可以完成瘦客戶機無法完成的任務
2.Web層 Web層由Web元件組成 ,J2EE Web元件包括JSP頁面和Servlets
Web層也可以包括一些JavaBeans Web層主要用來處理客戶請求,呼叫相應的邏輯塊,並把結果以動態網頁的形式返回到客戶端。
3.業務層(Business Tier) 業務層也叫EJB層或應用層，它由EJB伺服器和EJB元件組成
一 般情況下許多開發商把Web伺服器和EJB伺服器產品結合在一起釋出，稱為應用伺服器 .EJB層用來實現企業級資訊系統的業務邏輯。這是企業級應用的核心，由執行在業務層中的EJB來處理。一個Bean從客戶端接收資料、處理，然後把資料 送到企業資訊系統層儲存起來。同樣，一個Bean也可以從企業資訊系統取出資料，傳送到客戶端程式。業務層中的EJB要執行在容器中，容器解決了底層的問 題，如事務處理、生命週期、狀態管理、多執行緒安全管理、資源池等
4.企業資訊系統層（Enterprise Information System tier)處理企業系統軟體，包括企業基礎系統、資料庫系統及其他遺留的系統。J2EE支援連線架構（Connector Architecture)。提供連線J2EE平臺和企業資訊系統層的標準API。

9.EJB容器提供的服務？
容器提供的服務有很多,包括：1.元件池和壽命週期管理 2.客戶端會話管理 3.資料庫連線池
4.事務管理 5.驗證與訪問控制 6.永續性

10. EJB的角色和三個物件？
六個角色分別是EJB元件開發者（Enterprise Bean Provider） 、應用組合者（Application Assembler）、部署者（Deployer）、EJB 伺服器提供者（EJB Server Provider）、EJB 容器提供者（EJB Container Provider）、系統管理員（System Administrator）。三個物件是Remote（Local）介面、Home（LocalHome）介面，Bean類

11.你對spring+struts的耦合方式和原理？
使用了Spring的IoC來實元件之間的依賴關係注入, 使控制層與業務實現分離，即客戶通過
呼叫業務委託介面來呼叫具體的業務元件的例項，避免控制層與業務層的藕合帶來的維護
或升級困難。由Spring為DAO生成代理物件來為DAO新增事務服務，由IoC容器DAO的代理例項注入到業務元件中,業務元件通過DAO的委託介面呼叫DAO物件，使得上層元件不直接依賴於DAO的實現類，使得持久層更換或修改不影響上層元件。

12.對於apache common通訊包瞭解多少？
Commons BeanUtils
說明：針對Bean的一個工具集。由於Bean往往是有一堆get和set組成，所以BeanUtils也是在此基礎上進行一些包裝。
Commons Codec
說明：這個工具是用來編碼和解碼的，包括Base64，URL，Soundx等等。
Commons CLI
說明：這是一個處理命令的工具.比如main方法輸入的string[]需要解析。你可以預先定義好引數的規則，然後就可以呼叫CLI來解析。
Commons Collections
說明：你可以把這個工具看成是java.util的擴充套件。
Commons Configuration
說明：這個工具是用來幫助處理配置檔案的，支援很多種儲存方式
1. Properties files 2. XML documents 3. Property list files (.plist)
4. JNDI 5. JDBC Datasource 6. System properties 7. Applet parameters
8. Servlet parameters
Commons DBCP
說明：Database Connection pool, Tomcat就是用的這個
Commons DbUtils
說明：我以前在寫資料庫程式的時候，往往把資料庫操作單獨做一個包
Commons FileUpload
說明：jsp的上傳檔案功
Commons HttpClient
說明：這個工具可以方便通過程式設計的方式去訪問網站。
Apache Common BeanUtil
是一個常用的在物件之間複製資料的工具類，著名的web開發框架struts就是依賴於它進行ActionForm的建立。

13.Spring框架解析？
Spring既是全面的又是模組化的。Spring有分層的體系結構，這意味著你能選擇僅僅使用
它任何一個獨立的部分，而它的架構又是內部一致。因此你能從你的學習中，得到最大的
價值。例如，你可能選擇僅僅使用Spring來簡單化JDBC的使用，或用來管理所有的業務對
象。
它的設計從一開始就是要幫助你編寫易於測試的程式碼。Spring是使用測試驅動開發的工程
的理想框架。
Spring不會給你的工程新增對其他的框架依賴。Spring也許稱得上是個一站式解決方案，
提供了一個典型應用所需要的大部分基礎架構。它還涉及到了其他framework沒有考慮到的
內容。
Spring的核心即是個IoC/DI的容器，它可以幫程式設計人員完成元件之間的依賴關係注
入，使得元件之間的依賴達到最小，進而提高元件的重用性，Spring是個低侵入性（invas
ive）的框架，Spring中的元件並不會意識到它正置身於Spring中，這使得元件可以輕易的
從框架中脫離，而幾乎不用任何的修改，反過來說，元件也可以簡單的方式加入至框架
中，使得元件甚至框架的整合變得容易。
Spring最為人重視的另一方面是支援AOP（Aspect-Oriented Programming），然而AOP框架
只是Spring支援的一個子框架，說Spring框架是AOP框架並不是一件適當的描述，人們對於
新奇的 AOP關注對映至Spring上，使得人們對於Spring的關注集中在它的AOP框架上，雖然
有所誤解，但也突顯了Spring的另一個令人關注的特色。
Spring也提供MVC Web框架的解決方案，但您也可以將自己所熟悉的MVC Web框架與Spring
解合，像是Struts、Webwork等等，都可以與Spring整合而成為進用於自己的解決方案。Sp
ring也提供其它方面的整合，像是持久層的整合如JDBC、O/R Mapping工具（Hibernate、i
BATIS）、事務處理等等，Spring作了對多方面整合的努力，故說Spring是個全方位的應用
程式框架

14.Spring IoC底層執行原理？
Spring IoC 反向控制原理：
IoC，直觀地講，就是容器控制程式之間的關係，而非傳統實現中，由程式程式碼直接操控。這也就是所謂“控制反轉”的概念所在。控制權由應用程式碼中轉到了外 部容器，控制權的轉移是所謂反轉。IoC還有另外一個名字——“依賴注入（Dependency Injection）”。從名字上理解，所謂依賴注入，即元件之間的依賴關係由容器在執行期決定，形象地說，即由容器動態地將某種依賴關係注入到元件之 中。
反向控制是Spring框架的核心。通常，應用程式碼需要告知容器或框架,讓它們找到自身所需要的類,然後再由應用程式碼建立待使用的物件例項。 因此，應用程式碼在使用例項之前，需要建立物件例項。然而，IoC模式中,建立物件例項的任務交給IoC容器或框架(實現了IoC設計模式的框架也被稱為 IoC容器)，使得應用程式碼只需要直接使用例項[5]，這就是IoC。相對IoC 而言，“依賴注入”的確更加準確的描述了這種設計理念。所謂依賴注入，即元件之間的依賴關係由容器在執行期決定，形象的來說，即由容器動態的將某種依賴關 系注入到元件之中。
任何重要的系統都需要至少兩個相互合作的類來完成業務邏輯。通常，每個物件都要自己負責得到它的合作（依賴）物件。你會發現， 這樣會導致程式碼耦合度高而且難於測試。使用IoC，物件的依賴都是在物件建立時由負責協調系統中各個物件的外部實體提供的，這樣使軟體元件鬆散連線成為可 能。

15. Ajax是如何工作的？
Ajax 基本上就是把 JavaScript 技術和 XMLHttpRequest 物件放在 Web 表單和伺服器之間。當用戶填寫表單時，資料傳送給一些 JavaScript 程式碼而不是 直接傳送給伺服器。相反，JavaScript 程式碼捕獲表單資料並向伺服器傳送請求。同時使用者螢幕上的表單也不會閃爍、消失或延遲。換句話說，JavaScript 程式碼在幕後傳送請求，使用者甚至不知道請求的發出。更好的是，請求是非同步傳送的，就是說 JavaScript 程式碼（和使用者）不用等待伺服器的響應。因此使用者可以繼續輸入資料、滾動螢幕和使用應用程式。
然後，伺服器將資料返回 JavaScript 程式碼（仍然在 Web 表單中），後者決定如何處理這些資料。它可以迅速更新表單資料，讓人感覺應用程式是立即完成的，表單沒有提交或重新整理而使用者得到了新資料。 JavaScript 程式碼甚至可以對收到的資料執行某種計算，再發送另一個請求，完全不需要使用者干預！這就是 XMLHttpRequest 的強大之處。它可以根據需要自行與伺服器進行互動，使用者甚至可以完全不知道幕後發生的一切。結果就是類似於桌面應用程式的動態、快速響應、高互動性的體 驗，但是背後又擁有網際網路的全部強大力量。

16.列出曾經使用過的開源框架、工具以及類庫等？對哪些Web框架比較熟悉？分析 下這些Web框架的優缺點？
開源框架:struts、hiberante、spring、dwr
工具:eclipse3.4、MyEclipse5.5、JBuild、NetBeans、JBossIDE2.0、Dreamweave
類庫: Java提供的部分常用包
java.lang.*—— Java程式語言的基本類庫
java.util.*——– 包括集合類、時間處理模式、日期時間工具等各類常用工具包
java.io———–提供了通過資料流、物件序列以及檔案系統實現的系統輸入、輸出
java.sql———提供了訪問和處理來自於Java標準資料來源資料的類
java.applet—–提供了建立applet需要的所有類
java.awt.*——- 提供了建立使用者介面以及繪製和管理圖形、影象的類
javax.swing.*—- 提供了一系列輕量級的使用者介面元件，是目前Java使用者介面常用的包
java.math.*—— 提供了簡明的整數算術以及十進位制算術的基本函式
java.rmi———-提供了與遠端方法呼叫相關的所有類
javax.naming.*— 為命名服務提供了一系列類和介面
java.net———-提供了用於實現網路通訊應用的所有類
java.test———包括以一種獨立於自然語言的方式處理文字、日期、數字和訊息的類和介面
比較熟悉Web框架:struts1.2、struts2.0、spring mvc、WebWork
struts優缺點:
1. 實現MVC模式，結構清晰,使開發者只關注業務邏輯的實現.
2. 有豐富的tag可以用 ,Struts的標記庫(Taglib)，如能靈活動用，則能大大提高開發效率。另外，就目前國內的JSP開發者而言，除了使用JSP自帶的常用標記外，很少開發自己的標記，或許Struts是一個很好的起點。
3. 頁面導航.頁面導航將是今後的一個發展方向，事實上，這樣做，使系統的脈絡更加清晰。通過一個配置檔案，即可把握整個系統各部分之間的聯絡，這對於後期的維護有著莫大的好處。尤其是當另一批開發者接手這個專案時，這種優勢體現得更加明顯。
4. 提供Exception處理機制 .
5. 資料庫連結池管理
6. 支援I18N
缺點:
1、 轉到展示層時，需要配置forward，每一次轉到展示層，相信大多數都是直接轉到jsp，而涉及到轉向，需要配置forward，如果有十個展示層的 jsp，需要配置十次struts，而且還不包括有時候目錄、檔案變更，需要重新修改forward，注意，每次修改配置之後，要求重新部署整個專案，而 tomcate這樣的伺服器，還必須重新啟動伺服器，如果業務變更復雜頻繁的系統，這樣的操作簡單不可想象。現在就是這樣，幾十上百個人同時線上使用我們 的系統，大家可以想象一下，我的煩惱有多大。
2、 Struts 的Action必需是thread－safe方式，它僅僅允許一個例項去處理所有的請求。所以action用到的所有的資源都必需統一同步，這個就引起了執行緒安全的問題。
3、 測試不方便. Struts的每個Action都同Web層耦合在一起，這樣它的測試依賴於Web容器，單元測試也很難實現。不過有一個Junit的擴充套件工具Struts TestCase可以實現它的單元測試。
4、 型別的轉換. Struts的FormBean把所有的資料都作為String型別，它可以使用工具Commons-Beanutils進行型別轉化。但它的轉化都是在Class級別，而且轉化的型別是不可配置的。型別轉化時的錯誤資訊返回給使用者也是非常困難的。
5、 對Servlet的依賴性過強. Struts處理Action時必需要依賴ServletRequest 和ServletResponse，所有它擺脫不了Servlet容器。
6、 前端表示式語言方面.Struts集成了JSTL，所以它主要使用JSTL的表示式語言來獲取資料。可是JSTL的表示式語言在Collection和索引屬性方面處理顯得很弱。
7、 對Action執行的控制困難. Struts建立一個Action，如果想控制它的執行順序將會非常困難。甚至你要重新去寫Servlet來實現你的這個功能需求。
8、 對Action 執行前和後的處理. Struts處理Action的時候是基於class的hierarchies，很難在action處理前和後進行操作。
9、 對事件支援不夠. 在struts中，實際是一個表單Form對應一個Action類(或DispatchAction)，換一句話說：在Struts中實際是一個表單只能 對應一個事件，struts這種事件方式稱為application event，application event和component event相比是一種粗粒度的事件。
Struts重要的表單物件ActionForm是一種物件，它代表了一種應用，這個物件中至少包含幾個字 段，這些欄位是Jsp頁面表單中的input欄位，因為一個表單對應一個事件，所以，當我們需要將事件粒度細化到表單中這些欄位時，也就是說，一個欄位對 應一個事件時，單純使用Struts就不太可能，當然通過結合JavaScript也是可以轉彎實現的。
spring mvc優缺點: 他是一個典型的可以說是教科書式的mvc構架，而不像structs等都是變種或者不是完全基於mvc系統的框架，對於初學者或者想了解mvc的我覺得 spring是最好的，他的實現就是教科書！第二他和tapestry一樣是一個純正的servlet系統，這也是他和tapestry相比 structs所沒有的優勢。而且框架本身有程式碼，而且看起來也不費勁比較簡單可以理解。
缺點：使用人數少、jsp中要寫很多程式碼、控制器過於靈活，缺少一個公用控制器
WebWork 優缺點: 優點：結構簡單易於擴充套件、標籤庫易於定製、攔截器非常出色
缺點：文件示例很少、客戶端驗證技術不成熟

17.介紹幾種常用的設計模式：
1.業務委託模式：表示層元件將與業務層服務互動。這樣，業務層改變會使表示層也需要改變。業務委託模式可以解決這個問題。
業務委託模式的目的就是減少表示層和業務層的耦合，隱藏業務服務的各種複雜實現細節，如查詢與訪問細節。
2.會話門面模式：在伺服器方編寫服務層元件時，我們要處理複雜的企業Bean，封裝業務邏輯和資料。由於提供的介面很複雜，因此會使服務層也更復雜。會話門面設計模式可以減少這種複雜性。
會 話門面模式在需要隱藏業務層物件互動的細節時很有用。其主要意圖是處理幾種工作流。也就是管理業務物件，提供客戶的統一、粗粒度物件服務訪問。在物件術語 中，粗粒度物件具有自己的壽命週期，同時管理自己與其他物件的關係。此外，粗粒度物件的方法通常是高層的（例如addPerson（）而不是 setLastName（）、setFirstName（）之類的）。
3.數值物件設計模式：在用ejb框架建立的企業應用程式中，不同的分散式 元件之間需要交換資料。此外，前面曾介紹過，EJB框架將企業應用程式業務元件實現為會話Bean或實體Bean。而數值物件設計模式可以簡化企業 Bean之間的資料交換。用數值物件設計模式封裝業務資料。客戶向EJB請求業務資料是，EJB構造數值物件，在物件中填入資料，按數值傳遞給客戶。如果 客戶需要返回資料，則也差不多：構造數值物件，在物件中填入資料併發送給EJB。
4.累積實體設計模式：眾所周知，實體Bean主要用於持久存 儲。設計企業應用程式時，實體Bean不需要表示每個持久物件，這更適合資料結構方法。累積實體設計模式可以設計這種粗粒機制。累積實體設計模式用於建 模、表示和管理一組相關持久物件，而不是細粒實體Bean。它表示完整的物件圖。
5.工廠模式：工廠模式是一種經常被使用到的模式，根據工廠模式 實現的類可以根據提供的資料生成一組類中某一個類的例項，通常這一組類有一個公共的抽象父類並且實現了相同的方法，但是這些方法針對不同的資料進行了不同 的操作。首先需要定義一個基類，該類的子類通過不同的方法實現了基類中的方法。然後需要定義一個工廠類，工廠類可以根據條件生成不同的子類例項。當得到子 類的例項後，開發人員可以呼叫基類中的方法而不必考慮到底返回的是哪一個子類的例項。
6.DAO 模式通過對底層資料的封裝，為業務曾提供一個面向物件的介面，使得業務邏輯開發員可以面向業務中的實體進行編碼。通過引入DAO模式，業務邏輯更加清晰， 且富於形象性和描述性，這將為日後的維護帶來極大的便利。試想，在業務曾通過Customer.getName方法獲得客戶姓名，相對於直接通過SQL語 句訪問資料庫表並從ResultSet中獲得某個字元型欄位而言，哪種方式更加易於業務邏輯的形象化和簡潔化？
DAO模式,在專案開發中主要用在資料層，封裝資料的訪問操作，為業務層提供資料服務。
7.MVC模式,在J2EE專案開發中主要用在表示層框架中,很好解決檢視和流程控制。在專案中採用的Struts、WebWork等框架。
8.IoC模式,在專案開發中業務層有大量物件，他們之間存在依賴關係，可以使用IoC模式減少他們之間的程式碼耦合，提高系統的可擴充套件性。實際專案中使用的Spring框架來實現業務元件的裝配。
9.Observer模式，在Servlet的監聽器中應用到了觀察者模式。
10.singleton單例模式和Factory工廠模式結合使用在專案中無需使用者瞭解過多的細節就可獲取有關的物件例項。比如Hibernate專案中通過SessionFactory來獲取Session。
11.bridge模式，在專案中使用JDBC驅動訪問資料庫。

18.幾種常用的資料結構及內部實現原理？
連結串列：一個連結串列由很多節點組成，每個節點包含表示內容的資料域和指向下一個節點的鏈域兩部分。正是通過鏈域將節點連線形成一個表。圍繞連結串列的基本操作有新增節點、刪除節點和查詢節點等。
堆疊：限定了只能從線性表的一端進行資料的存取，這一端稱為棧頂，另一端為棧底。 入棧操作是先向棧頂方向移動一位，存入資料；出棧操作則是取出棧頂資料，然後向棧底移動一位。體現LIFO/FILO的思想。
佇列：限定了資料只能從線性表的一端存入，從另一端取出。存入一端成為隊尾，取出一端稱為隊首。體現LILO/FIFO的思想。
二叉樹：樹中的每個節點最多有兩個子節點。這兩個子節點分別稱為左子節點和右子節點。在建立二叉搜尋樹時，要求一個節點的左子節點的關鍵字值小於這個節點而右子節點的關鍵字值大於或等於這個節點。常見的遍歷操作有前序、中序和後序遍歷