【正文】 throw re。 (save successful)。 其具體代碼如下： public class CheckingrecordsInfoDAO extends HibernateDaoSupport { public void save(CheckingrecordsInfo transientInstance) { (saving CheckingrecordsInfo instance)。 的具體代碼如下： hibernatemapping class name= table=checkingrecords_info catalog=mdb lazy=false id name=recordId type= column name=record_id/ generator class=native / /id property name=itemName type= column name=item_name length=20 notnull=true / /property property name=status type= column name=Status notnull=true / /property /class /hibernatemapping Hibernate 的 DAO 操作模式 數(shù)據(jù)庫操作和持久層的對象是通過 DAO(數(shù)據(jù)訪問對象 )模式來實現(xiàn)的，每個持久層對象都會有自己的 DAO 文件 [12]。 } public void setStatus(Integer status) { = status。 } public void setItemName(String itemName) { = itemName。 } public void setRecordId(Integer recordId) { = recordId。 private Integer status。 數(shù)據(jù)庫中，資產(chǎn)核查表 checkingrecords_info 表有 recordId， itemName, status 等列名，該表映射為系統(tǒng)中的 CheckingrecordsInfo 對象， 的代碼具體如下： public class CheckingrecordsInfo implements { private Integer recordId。它還可以將一個用戶定義的多個類的實例映射到一張表的同一行，甚至可以利用代理模式來簡化載入類的過程。 數(shù)據(jù)持久層對象 Hibernate 是一種比較徹底的 Java 對象映射工具，支持使用各種 Java 思想如 Inheritance, Composition 等來實現(xiàn)對象。此數(shù)據(jù)庫負責應(yīng)用層從數(shù)據(jù)庫查詢數(shù)據(jù)，刪除數(shù)據(jù)，修改數(shù)據(jù)，向數(shù)據(jù)庫插入數(shù)據(jù)。 return (mapping, form, request, response)。 }else{ message = 刪除失??！ 。 String message =。 CheckingrecordsInfo delContent=(id)。 的具體代碼如下： public ActionForward delEdit(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) { DynaActionForm assetCheckForm = (DynaActionForm) form。 } AssetCheckAction(業(yè)務(wù)邏輯類 )通過 IOC(Inversion of Control)也稱賴性注射 (DependeneyIlljeetion)的模式來裝載和管理 CheckingrecordsBiz 類的實例。業(yè)務(wù)邏輯層中如果要調(diào)用delCheckingrecords()方法，要進行權(quán)限的判斷。 具體代碼如下： public interface CheckingrecordsBiz { public boolean delCheckingrecords(CheckingrecordsInfo id)。 本節(jié)以資產(chǎn)核查模塊中創(chuàng)建新的資產(chǎn)核查記錄的刪除功能為例來做以說明。 Spring AOP 的實現(xiàn)技術(shù)從本質(zhì) 上來講，是利用了 JDK 提供的動態(tài)代理 技術(shù)。 } } EquipmentInfoDAO 為 EquipmentBizImpl 中的一個私有對象，在 Spring 框架中，用 set 方法將 EquipmentInfoDAO 注入到 EquipmentBizImpl 中，其依賴關(guān)系在 中可以說明。 } public void setEquipmentDAO(EquipmentInfoDAO equipmentDAO) { = equipmentDAO。資產(chǎn)核查模塊查看所有表，獲得設(shè)備信息的功能接口實現(xiàn)類為EquipmentBizImpl 類，該類中的屬性對象為 EquipmentInfoDAO 類，具體代碼如下： public class EquipmentBizImpl implements EquipmentBiz{ private EquipmentInfoDAO equipmentDAO。 處理持久層和業(yè)務(wù)層的交互時，采用了 LOC 模式和面向接口的編程，使業(yè)務(wù)處理對象的 setter 方法接受的是接口，從而容易定義對象，實現(xiàn)依賴注入。 在處理 表現(xiàn)層與業(yè)務(wù)層間的交互耦合時，采用了一種新的 Fa231。方法中會返回一個 forward 界面如上例的“ checkAll” , 系統(tǒng)會到配置文件 下找到對應(yīng)的 forward. 然后跳轉(zhuǎn)到對應(yīng)的 jsp 截面。 return (checkAll)。 ListEquipmentInfo equipment=()。它繼承 Struts 的MappingDispatchAction 類。下面列舉出觸發(fā)四個功能選項的代碼。 forward標簽的 path 即為 MVC 的 view。 action標簽標示訪問請求的接受、轉(zhuǎn)發(fā)、接受、返回的過程配置。由于代碼過多，這里只列舉出查看所有表單功能的配置文件 。 MVC 模式的 Module： Controller 轉(zhuǎn)發(fā)訪問請求所到達的第一層，即 MVC 的 Module，在程序中表現(xiàn)為 類。 Struts 的配置文件： 。 圖 ：歷史資產(chǎn)核查表單 創(chuàng)建核查表單如圖 所示：顯示新的資產(chǎn)核查表，界面把上次資產(chǎn)核查表作為參考，通過對上次的 資產(chǎn)核查操作，編輯或刪除。點擊查看所有表單鏈接會在右邊的框中顯示所有包括車輛、房產(chǎn) 、設(shè)備三張 表的資產(chǎn)記錄。 第五章 資產(chǎn)核查模塊的設(shè)計與實現(xiàn) 資產(chǎn)核查模塊界面設(shè)計及功能說明 界面風格設(shè)計 資產(chǎn)核查模塊界面采用和整個 EAM 系統(tǒng)相同的界面的風格， 即一個 Tabel鑲嵌多個 JSP 文件 ，每次 變化一個小的 JSP 界面，設(shè)計思想為整體刷新，局部變化。 附加功能 附加功能一 ：核查者查出 根據(jù)部門查處所有有誤的資產(chǎn)，得到新的表單并發(fā)送給各部門經(jīng)理，再由部門經(jīng)理核對。具體的核對流程是：資產(chǎn)變動情況 (+/)上次資產(chǎn)核查表單 是否等于 所有資產(chǎn)表。 創(chuàng)建資產(chǎn)核查新記錄 創(chuàng)建資產(chǎn)核查記錄是對上次的資產(chǎn)核查進行編輯操作，具體的操作詳細到每條記錄，界面顯示上次的資產(chǎn)核查記錄，并提供編輯，刪除，保存的操作。歷史資產(chǎn)核查表為表 ： 表 ：歷史資產(chǎn)核查表 CHECKINGRECORDS_INFO 資產(chǎn)核查信息表 列名 數(shù)據(jù)類型 主鍵 約束 默認值 對應(yīng)字典 數(shù)據(jù)項 描述 RECORD_ID INT 是 必填 維護 ID ITEM_NAME VARCHAR(20) 必填 產(chǎn)品名稱 AMOUNT INT 必填 產(chǎn)品數(shù)量 PRICE DOUBLE 必填 產(chǎn)品單價 DEPARTMENT INT 必填 所在部門 外鍵 STATUS INT 必填 資產(chǎn)狀態(tài) DATE DATE 必填 核查日期 歷史資產(chǎn)核查記錄將是 對創(chuàng)建新的資產(chǎn)核查記錄起參考作用，新的資產(chǎn)核查記錄只是對上次資產(chǎn)核查記錄的編輯和修改。所要查詢的 數(shù)據(jù)表為資產(chǎn)維修，增加及報廢信息表，表如 ： 表 ： 維修報廢及遺失申請表 MAINTAIN_INFO 維護信息表 列名 數(shù)據(jù)類型 主鍵 約束 默認值 對應(yīng)字典 數(shù)據(jù)項 描述 ITEM_ID VARCHAR(10) 是 必填 維護 ID NAME VARCHAR(2 必填 產(chǎn)品名稱 0) TAG_CODE INT 必填 分類代碼 TYPE INT 必填 0:維修 1:報廢 2:遺失 維護類型 DATE DATE 必填 維護日期 DEPARTMENT VARCHAR(20) 必填 所在部門 REASON VARCHAR(50) 原因 所有修改記錄在頁面只需顯示出資產(chǎn)名稱，資產(chǎn)數(shù)量，及資產(chǎn)日期，變動情況，變動情況是關(guān)鍵，將由核查者根據(jù)此記錄來 創(chuàng)建新的資產(chǎn)核查表單 。 查詢所有修改記錄 查詢所有修改記錄是對從上次資產(chǎn)核查開始到本月資產(chǎn)核查之間 ，查詢出所有變動的資產(chǎn)情況。其流程為登陸界面，然后點擊資產(chǎn)核查，點擊彈出框的查看所有資產(chǎn)頁面，進入核查窗口。核查者通過查看所有表格的信息獲取資產(chǎn)的大致了解情況。核查者可根據(jù)不同資產(chǎn)、時間、部門、修改狀況、資產(chǎn)變化情況等來方便的查詢出企業(yè)的資產(chǎn)現(xiàn)狀。另外，本模塊可以分部門清查出有誤的核對結(jié)果，可以把表單發(fā)送給各部門，以便各部門再進行確認，各部門將確認的結(jié)果可以提交給核查者，擁有靈活的互動能力。然后，資產(chǎn)核查者根據(jù)部門分出不同的資產(chǎn)核查表單，并發(fā)送給各部門經(jīng)理，各部門經(jīng)理進行各部門的資產(chǎn)核對；最后，各部門經(jīng)理發(fā)送回各部門的資產(chǎn)核對表，由資產(chǎn)核查者核對，錄入最終的資產(chǎn)核查結(jié)果表。 EAM 引入資產(chǎn)核查模塊作為其業(yè)務(wù)層開發(fā)的平臺，為企業(yè)資產(chǎn)明細，核算提供流程支持。最后，對企業(yè)資產(chǎn)管理系統(tǒng)做的維護工作，后臺管理員占的比重較大，包括權(quán)限的維護，部門的維護，數(shù)據(jù)的備份和還原，操作的記錄等。員工可以修改個人賬號和密碼。不同之處在于表單的填寫更加詳細，且由自己來明確信息。這個模塊和資產(chǎn)申報模塊的流程類似。 資產(chǎn)申報模塊業(yè)務(wù)不是很復(fù)雜，但要做到及時更新信息，這樣其他幾個子模塊就能得到各自的及時信息。員工只有申請的權(quán)限。員工填 寫資產(chǎn)明細卡，提交購物表單，等待部門經(jīng)理的批示。 (第四章將對此做出詳細說明 ) 資產(chǎn)申報模塊 資產(chǎn)申報模塊包括兩部分：一為網(wǎng)上購物；二為報廢及維修設(shè)備申請。 本模塊要求對 EAM 系統(tǒng)中的所有報表都有查詢的功能，包括通用及專用設(shè)備類信息表，交通運輸類信息表，房屋住宅信息表及資產(chǎn)報廢和維修信息表組成。授權(quán)核查的個人可以在次系統(tǒng)中查看 所有的資產(chǎn)情況，查看資產(chǎn)變動情況，通過結(jié)合上次的 資產(chǎn)核查清單來核查企業(yè)的本階段資產(chǎn)是否有誤。 EAM 系統(tǒng)的模塊結(jié)構(gòu) EAM 系統(tǒng)共有個子模塊：資產(chǎn)核查模塊、網(wǎng)上購物模塊、資產(chǎn)申請模塊、以及 后臺管理模塊。 可靠性高 。 可擴充性好 。 功能完善 。 授權(quán)操作不能太復(fù)雜，一個界面可授予不同的用戶組不同的內(nèi)容，菜單授權(quán)和界面授權(quán)等操作簡單，并可隨時修改。 系統(tǒng)的邏輯結(jié)構(gòu)非常清晰、合理、層次性強，不能讓大多數(shù)人理解困難，摒棄人為制造的復(fù)雜結(jié)構(gòu)。這實際上是一種模型的 變化 傳播機制。如果用戶通過某個視圖的控制器改變了模型的數(shù)據(jù)，所有其它依賴于這些數(shù)據(jù)的視圖都應(yīng)反映到這些變化。因此，一個模型可能對應(yīng)多個視圖，一個視圖可能對應(yīng)多個模型?？刂茖硬⒉蛔鋈魏蔚臄?shù)據(jù)處理。 控制 (Controller)可以理解為從用戶接收請求 ,將模型與視圖匹配在一起，共同完成用戶的請求。比如將一張訂單保存到數(shù)據(jù)庫，從數(shù)據(jù)庫獲取訂單。 業(yè)務(wù)模型還有一個很重要的模型那就是數(shù)據(jù)模型。抽象與具體不能 隔得太遠，也不能太近。對一個開發(fā)者來說，就可以專注于業(yè)務(wù)模型的設(shè)計。目前流行的 EJB 模型就是一個典型的應(yīng)用例子，它從應(yīng)用技術(shù)實現(xiàn)的角度對模型做了進一步的劃分，以便充分利用現(xiàn)有的組件，但它不能作為應(yīng)用設(shè)計模型的框架。業(yè)務(wù)流程的處理過程對其它層來說是黑箱操作，模型接受視圖請求的數(shù)據(jù)，并返回最終的處理