這條HQL語句查詢Customer表，根據custlevel分組查詢有多少條記錄。

 問題一：如果用

count計數并且是已Group by分組的話,count查詢的必須是分組的字段.

 問題二：通過query.list()返回一個結果， 在JSP頁面中的顯示可以用JSTL,代碼如下：

該如何去把這個結果轉換為Pojo？

query.list();返回的List集合裝載的是一個一個的Object []，如果要賦予Pojo屬性可以這樣：

import java.util.List;

import org.hibernate.Query;

import org.springframework.orm.hibernate3.support.HibernateDaoSupport;

/*

 * 最基本的DAO操作,已供應其他類來調用

 */

public class BaseDAO extends HibernateDaoSupport {

    /*

     * 添加

     */

    public boolean addObject(Object obj) {

       boolean state = true;

       try {

           this.getHibernateTemplate().save(obj);

       } catch (Exception e) {

           e.printStackTrace();

           state = false;

       }

       return state;

    }

    /*

     * 刪除

     */

    public boolean delObject(Object obj) {

       boolean state = true;

       try {

           this.getHibernateTemplate().delete(obj);

       } catch (Exception e) {

           state = false;

       }

       return state;

    }

}

這個類是最原始的去DAO，封裝了一些數據的增刪查改，然后我編寫了數據訪問接口，數據訪問的實現類繼承自這個類再實現接口。代碼如下：

import com.custservice.base.BasdBase;

import com.custservice.basicdao.BaseDAO;

public class BasdService extends BaseDAO implements BasdBase {

    public boolean delete(Object obj) {

       return super.delObject(obj);

    }

    public boolean saveObj(Object obj) {

       return super.addObject(obj);

    }

}

當我AOP的切入點配置到BaseDAO是事務是不會提交的，這個事務的切入點必須配置到直接訪問數據庫類的上一層。配置文件如下：

<tx:advice id="txAdvice" transaction-manager="transactionManager">

       <tx:attributes>

           <tx:method name="save*" propagation="REQUIRED" />

           <tx:method name="update*" propagation="REQUIRED" />

           <tx:method name="del*" propagation="REQUIRED" />

           <tx:method name="*" read-only="true" />

       </tx:attributes>

    </tx:advice>

    <aop:config>

       <aop:pointcut id="allMethod"

           expression="execution(* com.custservice.service.*.*(..))" />

       <aop:advisor pointcut-ref="allMethod" advice-ref="txAdvice" />

二。問題場景
首先，我們應該先了解為什么要處理這樣的問題？或者專業一點就是它適合的場景是什么？（似乎只有人來問沒有人來解釋）

1。重復提交、重復刷新的場景
重復提交、重復刷新都是來解決系統重復記錄的問題。也就是說某個人在多次的提交某條記錄（為什么？也許是閑了沒有事情干的;最有可能是用戶根本就不知道自己的提交結果是否已經執行了？?。?/p>

但出現了這樣的問題并不見得就必須處理，要看你所開發的系統的類別而定。比如你接手的是某個資源管理系統，系統本身從需求的角度根本就不允許出現" 重復"的記錄，在這樣需求的約束條件下，去執行重復的提交動作只會引發“業務級異常”的產生，根本就不可能執行成功也就無所謂避免不避免的問題了。

2。防止后退的場景
了解了重復刷新、重復提交的場景，我們來了解一下"防止后退"操作的原因是什么？比如你在開發某個投票系統，它有很多的步驟，并且這些步驟之間是有聯系 的，比如第一步會將某些信息發送給第二步，第二步緩存了這些信息，同時將自身的信息發送給了第三步。。。。。等等，如果此時用戶處在第三步驟下，我們想象 一下某個淘氣用戶的用戶點擊了后退按鈕，此時屏幕出現了第二步驟的頁面，他再次的修改或者再次的提交，進入到下一個步驟（也就是第三步驟），錯誤就會在此 產生？！什么錯誤呢？最為典型的就是這樣的操作直接導致了對于第一個步驟信息的丟失！（如果這樣的信息是依靠Request存放的話，當然你可以存放在 Session或者更大的上下文環境中，但這不是個好主意！關于信息存放的問題，下次在就這個問題詳細的討論）

三。如何處理的問題
當然很多的系統（比如訂票系統從需求上本身是允許個人重復訂票的）是必須要避免重復刷新、重復提交、以及防止后退的問題的，但即使是這樣的問題，也要區分 如何處理以及在哪里處理的（網上只是告訴你如何處理，但很少去區分在哪里處理的），顯然處理的方式無非是客戶端或者服務器端兩種，而面對不同的位置處理的 方式也是不同的，但有一點要事先聲明：任何客戶端（尤其是B/S端）的處理都是不可信任的，最好的也是最應該的是服務器端的處理方法。

客戶端處理：
面對客戶端我們可以使用Javascript腳本來解決，如下

1。重復刷新、重復提交
Ways One：設置一個變量，只允許提交一次。
<script language="javascript">
    var checkSubmitFlg = false;
    function checkSubmit() {
      if (checkSubmitFlg == true) {
         return false;
      }
      checkSubmitFlg = true;
      return true;
   }
   document.ondblclick = function docondblclick() {
    window.event.returnValue = false;
   }
   document.onclick = function doconclick() {
       if (checkSubmitFlg) {
         window.event.returnValue = false;
       }
   }
</script>
<html:form action="myAction.do" method="post" onsubmit="return checkSubmit();">

Way Two : 將提交按鈕或者image置為disable
<html:form action="myAction.do" method="post"
    onsubmit="getElById('submitInput').disabled = true; return true;">  
<html:image styleId="submitInput" src="images/ok_b.gif" border="0" />
</html:form>

2。防止用戶后退
這里的方法是千姿百態，有的是更改瀏覽器的歷史紀錄的，比如使用window.history.forward()方法;有的是“用新頁面的URL替換當 前的歷史紀錄，這樣瀏覽歷史記錄中就只有一個頁面，后退按鈕永遠不會變為可用。”比如使用 javascript:location.replace(this.href); event.returnValue=false;

2.服務器端的處理（這里只說Struts框架的處理）
利用同步令牌（Token）機制來解決Web應用中重復提交的問題，Struts也給出了一個參考實現。

基本原理：
服務器端在處理到達的請求之前，會將請求中包含的令牌值與保存在當前用戶會話中的令牌值進行比較，
看是否匹配。在處理完該請求后，且在答復發送給客戶端之前，將會產生一個新的令牌，該令牌除傳給
客戶端以外，也會將用戶會話中保存的舊的令牌進行替換。這樣如果用戶回退到剛才的提交頁面并再次
提交的話，客戶端傳過來的令牌就和服務器端的令牌不一致，從而有效地防止了重復提交的發生。

if (isTokenValid(request, true)) {
    // your code here
    return mapping.findForward("success");
} else {
    saveToken(request);
    return mapping.findForward("submitagain");
}

Struts根據用戶會話ID和當前系統時間來生成一個唯一（對于每個會話）令牌的，具體實現可以參考
TokenProcessor類中的generateToken()方法。

1. //驗證事務控制令牌,<html:form >會自動根據session中標識生成一個隱含input代表令牌，防止兩次提交
2. 在action中：

       //<input type="hidden" name="org.apache.struts.taglib.html.TOKEN"
       // value="6aa35341f25184fd996c4c918255c3ae">
       if (!isTokenValid(request))
           errors.add(ActionErrors.GLOBAL_ERROR,
                      new ActionError("error.transaction.token"));
       resetToken(request); //刪除session中的令牌

3. action有這樣的一個方法生成令牌
   protected String generateToken(HttpServletRequest request) {
       HttpSession session = request.getSession();
       try {
           byte id[] = session.getId().getBytes();
           byte now[] =
               new Long(System.currentTimeMillis()).toString().getBytes();
           MessageDigest md = MessageDigest.getInstance("MD5");
           md.update(id);
           md.update(now);
           return (toHex(md.digest()));
       } catch (IllegalStateException e) {
           return (null);
       } catch (NoSuchAlgorithmException e) {
           return (null);
       }
   }

總結
對于重復提交、重復刷新、防止后退等等都是屬于系統為避免重復記錄而需要解決的問題，在客戶端去處理需要針對每一種的可能提出相應的解決方案，然而在服務器端看來只不過是對于數據真實性的檢驗問題，基于令牌的處理就是一勞永逸的方法。

同時我們也看到，從不同的角度去看待問題，其解決的方法也是不同的。客戶端更追求的是用戶的操作，而服務端則將注意力放在了數據的處理上，所以在某 個對于服務器端看似容易的問題上，用客戶端來解決卻麻煩了很多！反之依然。所以在某些問題的處理上我們需要綜合考慮和平衡，是用客戶端來解決？還是用服務 器端來處理？

create table tb
(
Name    varchar(10) ,
Subject varchar(10) ,
Result  int
)
insert into tb(Name , Subject , Result) values('張三' , '語文' , 74)
insert into tb(Name , Subject , Result) values('張三' , '數學' , 83)
insert into tb(Name , Subject , Result) values('張三' , '物理' , 93)
insert into tb(Name , Subject , Result) values('李四' , '語文' , 74)
insert into tb(Name , Subject , Result) values('李四' , '數學' , 84)
insert into tb(Name , Subject , Result) values('李四' , '物理' , 94)
go
--靜態SQL,指subject只有語文、數學、物理這三門課程。
select name 姓名,
max(case subject when '語文' then result else 0 end) 語文,
max(case subject when '數學' then result else 0 end) 數學,
max(case subject when '物理' then result else 0 end) 物理
from tb
group by name

--動態SQL,指subject不止語文、數學、物理這三門課程。
declare @sql varchar(8000)
set @sql = 'select Name as ' + '姓名'
select @sql = @sql + ' , max(case Subject when ''' + Subject + ''' then Result else 0 end) [' + Subject + ']'
from (select distinct Subject from tb) as a
set @sql = @sql + ' from tb group by name'
exec(@sql) 

--靜態SQL,指subject只有語文、數學、物理這三門課程。
select name 姓名,
max(case subject when '語文' then result else 0 end) 語文,
max(case subject when '數學' then result else 0 end) 數學,
max(case subject when '物理' then result else 0 end) 物理,
cast(avg(result*1.0) as decimal(18,2)) 平均分,
sum(result) 總分
from tb
group by name

--動態SQL,指subject不止語文、數學、物理這三門課程。
declare @sql1 varchar(8000)
set @sql1 = 'select Name as ' + '姓名'
select @sql1 = @sql1 + ' , max(case Subject when ''' + Subject + ''' then Result else 0 end) [' + Subject + ']'
from (select distinct Subject from tb) as a
set @sql1 = @sql1 + ' , cast(avg(result*1.0) as decimal(18,2)) 平均分,sum(result) 總分 from tb group by name'
exec(@sql1) 

Hibernate中的一對多映射，以一個學校對應多個學生舉例。

Pojo--> Student

Pojo --> School

Set students表示被裝載的Student類對象的唯一標識信息，在一對多的映射當中充當外鍵的作用。

再來看看hbm.xml配置信息，Student的配置信息很簡單，因為是被映射的基本上只需配置簡單的屬性即可。

而School的配置信息就得配置從School類的主鍵到Student類外鍵的映射關系。

Hibernate.cfg.xml中配置這兩個XML的路徑即可。。。

我們來插入兩個學生和一個學校測試一下：

MySQL結果為：

Struts是Apache組織研發的一個MVC開源框架，基于J2EE平臺，目前我學習的版本是1.3.8，接近兩個禮拜的學習后，寫下此筆記。

首先應該從普通的JSP+Servlet+JavaBean(后文略寫為JSJ)談起，這樣的話才能體現出Struts框架的優秀特點，這里我把純JSP開發和Struts1.X做個對比。

1.JSJ開發Web應用時，把經常用到的數據全部封裝JavaBean，在當時看來，這是件很好的事情，但是當我們的Web應用變得相對比較龐大時就暴露出JavaBean的不足，當獲取到數據時，我們難免都要get or set數據一下，這無疑是純粹的手工勞動，那有什么解決方法呢？我們留到后面講。

2.JSP傳遞參數到Servlet的時候，Servlet使用HttpServletRequest對象的getParameter方法接收JSP傳遞過來的參數，當表單的數據量比較多的時候，呵呵，比如一個資料比較詳細的用戶注冊，

那么只能寫N多個getParameter。

3.當要做多個業務的時候，比如做一個用戶登錄和購物的例子，使用JSJ開發的時候需要把相應的業務傳到Servlet的doGet or doPost方法中根據傳遞的參數進行判斷需要調用哪個Model，像購物車有添加商品、修改商品數量、刪除商品、購買、清空購物車等等操作，我們用JSJ的時候是不是根據動作參數來判斷是購買呢還是刪除？那這樣的話就購物業務的Servlet的doGet or doPost中就寫了許多的判斷動作的代碼，前期寫的時候也許條理很清晰，但是后期維護的話是相當麻煩的。

Struts1.X解決這些贅重問題有了一套非常不錯的MVC架構，層與層之間的耦合度縮小使開發人員后期維護變得不那么復雜，但節省代碼量就得付出配置的代價，Struts1.X的struts-config.xml為Struts專用的xml配置文件，當我們添加MyE的Struts支持時，此文件就已經生成了，如果你要更改struts-config.xml的名稱，同時你就得必須在Web.xml中修改加載時讀入的xml文件名，如下：

<init-param>

<param-name>config</param-name>

<param-value>/WEB-INF/struts-config.xml</param-value>  ／／改成你修改后的名稱

</init-param>

我們打開web.xml來分析一下下面這幾對標簽

<servlet-name>action</servlet-name>

<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>

<servlet-mapping>

    <servlet-name>action</servlet-name>

    <url-pattern>*.do</url-pattern>

 </servlet-mapping>

ActionServlet為Struts1.X的前端控制的Servlet，此Servlet的作用把struts-config.xml中配置的信息映射到相應的操作中，在添加Struts1.X支持的時候我們習慣性的使用action這個名字，上面的<servlet-mapping>標簽又起到一個什么樣的作用呢？我們可以把ActionServlet想像成一個前端攔截器，<url-pattern>*.do</url-pattern>是攔截所有以.do結尾的路徑。

說到前端控制器我們不得不思考一個問題，JSJ有沒有前端控制器、既然有前端控制器那有沒有后端控制器？

答案是JSJ中有前端控制器但沒有后端控制，我們以前用JSJ開發的時候是的都是一個一個的Servlet堆砌出來的前端控制，當用戶提交操作的時候通過form的Action路徑找到相應的控制然后調用相應的Model業務，這樣做不好的地方我們上面已經說過，故此不添贅言。

而我們理想的狀態是當用戶提交操作的時候不需要進入前端控制器編寫代碼來判斷需要那種業務，當然配置映射是無可避免的，不寫代碼又不配置，沒有這樣好的事情。我們再來看一下ActionServlet是怎么根據用戶的提交調用相應的后端控制器，打開struts-config.xml分析一下，我們看一下<action-mappings>這個標簽，見名之意，此標簽為一個動作映射的配置，它里面有一個子標簽叫<action> ，在這個Action標簽里我們配置映射信息，比如

<action-mappings>

       <action name=”form_name”input=”/發生錯誤后跳轉的頁面” path=”/action提交的名稱”type=”后端控制器的全文路徑”>   ///如果你的某個后端控制器有多個方法的話，則要在此標簽里添加一個parameter屬性，屬性內容為你傳遞參數判斷調用那個方法的變量名

             <forward  name=”key”path=”/pathName” /> //跳轉路徑，name為跳轉頁面(path屬性)相應的key

</action>

</action-mappings>

可在action-mappings標簽中添加多個action子標簽,

服務器啟動的時候自動在Web.xml中編譯ActionServlet，并把struts-config.xml全部讀到內存中，如果是第一次加載則創建動態Form，如果已編譯過此Form則把Form映射到Action中，通過action標簽映射到對應的類文件中。這就是ActionServlet的作用。

我們再來談談那些后端控制器，ActionServlet既然可以攔截所有以.do結尾的路徑名，我們應該想想。。。用戶從頁面提交參數到服務器，那么服務器的一些控制已經通過xml配置好了，那么它做業務分發的時候怎么傳遞請求響應和表單數據呢？

這里Struts1.X類叫Action，這個Action有一個方法叫

我們來看看這四個參數的用法，ActionMapping封裝了一些映射的信息，比如找到服務器轉發的跳轉路徑。ActionForm封裝了表單信息, 其他兩個參數為就不介紹了，當用戶從頁面把表單提交到服務器的時候，通過XML的配置自動會調用ActionForm類的execute方法，execute方法只有一個，業務多的話，我們怎么再做分發呢？

Struts1.X有一個類叫DispatchAction實現于Actiond的子類BaseAction，DispatchAction，而這個DispatchAction的execute方法與Action的execute方法參數一樣，并且可以更改為你自己想要的名稱，需要注意的是更改的方法必須與傳遞過來的參數值一致，這樣的話我們就可以做到一個動態的后端控制器.

我們還要談一下ActionForm，寫一個類繼承自ActionForm重寫它的兩個方法

Reset方法為保證數據的安全性，在傳入表單數據清空其字段。

Validate為驗證其字段，默認返回錯誤為空，程序將往下執行，如果你編寫代碼判斷出錯的話，則跳轉到struts-config.xml的action標簽的input屬性值中，此input屬性較好的解釋應該是error。

當在外界程序需要設置自己編寫的ActionForm子類的字段時，需要用此對象調用 get or set方法，這種get or set完全可以用DynaActionForm所代替，但實體的DTO有時候還是蠻有用的。我們再來看一下ActionForm在XML中的配置信息：

<form-beans>

              <form-bean  name=”form_name” type=”ActionForm子類的原文路徑” />

   ///當我們配置action標簽的時候，action的name屬性值就是你配置的form-bean的name屬性值

</ form-beans>

這個實體的DTO不好的地方是需要編寫一個類繼承自ActionForm，而DynaActionForm就做到了把bean信息完全封裝在struts-config.xml，我們看一下：

       <form-beans>

              <form-bean name="userinfo"

                     type="org.apache.struts.action.DynaActionForm">

                     <form-property name="id" type="java.lang.Integer" />

                     <form-property name="username" type="java.lang.String" />

                     <form-property name="password" type="java.lang.String" />

              </form-bean>

       </form-beans>

我們現在配置的bean信息是在<form-beans>標簽里面配置，需要注意的是form-bean的類型是DynaActionForm，<form-property>標簽里封裝了以前在DTO中的字段，那么我們就可以用這個form-bean的name屬性值映射到<form-property>里配置的字段了。

此筆記還得記錄一下Struts1.X的架構思想，用一個關于賣衣服和鞋子工廠的例子來概述一下：

如果要開辦一家工廠，首先應該想到的是做什么東西，比如我要做衣服和鞋子，而衣服和鞋子必須得有料子才行，所以我得先弄到料子（DTO或DynaActionForm），這個料子可能不止一種，所以我得先弄到我需要的料子(編寫或配置不同的DTO或DynaActionForm)，那么我還得創建做衣服和鞋子的部門(類似于DAO等等)，部門經理總得有個上級吧，部門經理的上級叫某某經理(DispatchAction)，這個某某經理只需要把總經理(ActionServlet)交代要做的一些事情分給下面的部門經理，返回東西給他就行。而總經理上面還有個頭兒是董事長(View)，這個董事長只需要把他需要的信息告訴下級并且返回東西給董事長就行了，其他的一些制度和約束(XML)都明擺著，按照這個流程運轉就OK了。

這是我的理解，有些粗糙，但本質上是這樣子的，具體的話還的多花時間去學習。期待Struts2.X。。。