內(nèi)網(wǎng)J2EE架構需求說明書1架構需求說明總體架構圖V層（視圖層）：包括jsp

、html等，該層只負責顯

示數(shù)據(jù)的功能，沒有任何

業(yè)務邏輯。一般是從requ

est中取得相應數(shù)據(jù)。C層（控制層）：包括struts

的action、Servlet等，該層

負責權限控制、接收V層的

數(shù)據(jù)、調(diào)用業(yè)務代理、重

定向頁面。M層（模型層）：包括javaBean、ejb、jms、jmail、jts、自己封裝的組件等，主要可以分為l兩個子層：代理層、DAO層（持久層）1/8內(nèi)網(wǎng)J2EE架構需求說明書架構時序圖1\在任何地方出現(xiàn)致命異常，都要中止執(zhí)行，回滾事物、并以友好的方式提示用戶、將錯誤軌跡寫入日志，允許的話，要將錯誤以郵件或者短信提示系統(tǒng)管理員。架構基本需求說明該章節(jié)描述每一層都需要的考慮和注意的問題，及一些必須遵循的原則。命名規(guī)范需求詳見pvcs上的“java命名規(guī)范.doc”2/8內(nèi)網(wǎng)J2EE架構需求說明書異常處理需求在任何地方出現(xiàn)致命異常，都要中止執(zhí)行，回滾事物、并以友好的方式提示用戶、將錯誤軌跡寫入日志，允許的話，要將錯誤以郵件或者短信提示系統(tǒng)管理員。異常處理必須遵循以下幾個原則：.不能丟棄異常既然捕獲了異常，就要對它進行適當?shù)奶幚?。不要捕獲異常之后又把它丟棄，不予理睬。捕獲了異常卻不作任何處理，可以算得上Java編程中的殺手。如果你看到了這種丟棄（而不是拋出）異常的情況，可以百分之九十九地肯定代碼存在問題（在極少數(shù)情況下，這段代碼有存在的理由，但最好加上完整的注釋，以免引起別人誤解）。異?？偸且馕吨承┦虑椴粚帕耍蛘哒f至少發(fā)生了某些不尋常的事情，我們不應該對程序發(fā)出的求救信號保持沉默和無動于衷。調(diào)用一下printStackTrace算不上“處理異?！?。不錯，調(diào)用printStackTrace對調(diào)試程序有幫助，但程序調(diào)試階段結束之后，printStackTrace就不應再在異常處理模塊中擔負主要責任了。正確對待異常方式主要有四種：1）處理異常。針對該異常采取一些行動，例如修正問題、提醒某個人或進行其他一些處理，要根據(jù)具體的情形確定應該采取的動作。調(diào)用printStackTrace算不上已經(jīng)“處理好了異?！?。2）重新拋出異常。處理異常的代碼在分析異常之后，認為自己不能處理它，重新拋出異常也不失為一種選擇。3）把該異常轉(zhuǎn)換成另一種異常。大多數(shù)情況下，這是指把一個低級的異常轉(zhuǎn)換成應用級的異常（其含義更容易被用戶了解的異常）。4）不要捕獲異常。方法必須有throws來拋出異常。.必須指定具體的異常在catch語句中盡可能指定具體的異常類型，必要時使用多個catch。不要試圖處理所有可能出現(xiàn)的異常。.占用資源必須釋放保證所有資源都被正確釋放。充分運用finally關鍵詞。finally是樣好東西：不管是否出現(xiàn)了異常，F(xiàn)inally保證在try/catch/finally塊結束之前，執(zhí)行清理任務的代碼總是有機會執(zhí)行。當然，編寫finally塊應當多加小心，特別是要注意在finally塊之內(nèi)拋出的異常，這是執(zhí)行清理任務的最后機會，盡量不要再有難以處理的錯誤。3/8內(nèi)網(wǎng)J2EE架構需求說明書.必須說明異常的詳細信息在出現(xiàn)異常時，最好能夠提供一些文字信息，例如當前正在執(zhí)行的類、方法和其他狀態(tài)信息，使其易于理解和閱讀。.不能使用過于龐大的try塊把大量的代碼放入單個try塊，然后再在catch語句中聲明Exception，而不是分離各個可能出現(xiàn)異常的段落并分別捕獲其異常。這種做法為分析程序拋出異常的原因帶來了困難，因為一大段代碼中有太多的地方可能拋出Exception。.輸出數(shù)據(jù)不完整不完整的數(shù)據(jù)是Java程序的隱形殺手。考慮一下如果循環(huán)的中間拋出了異常，會發(fā)生什么事情。循環(huán)的執(zhí)行當然是要被打斷的，其次，catch塊會執(zhí)行，就這些，再也沒有其他動作了。已經(jīng)輸出的數(shù)據(jù)怎么辦？使用這些數(shù)據(jù)的人或設備將收到一份不完整的（因而也是錯誤的）數(shù)據(jù)，卻得不到任何有關這份數(shù)據(jù)是否完整的提示。對于有些系統(tǒng)來說，數(shù)據(jù)不完整可能比系統(tǒng)停止運行帶來更大的損失。較為理想的處置辦法是向輸出設備寫一些信息，聲明數(shù)據(jù)的不完整性；另一種可能有效的辦法是，先緩沖要輸出的數(shù)據(jù)，準備好全部數(shù)據(jù)之后再一次性輸出。日志管理需求日志管理模塊可以產(chǎn)生便于最終用戶、系統(tǒng)管理員、故障維護工程師以及軟件開發(fā)團隊進行分析的事件記錄，它為軟件的開發(fā)調(diào)試和維護提供便利的手段。它能捕獲操作系統(tǒng)平臺和執(zhí)行程序的安全故障、配置錯誤、執(zhí)行瓶頸和（或）Bug等數(shù)據(jù)信息，以純文本、XML或程序員自定的某種方式將其格式化成日志記錄，然后傳遞給內(nèi)存、系統(tǒng)輸出流、控制臺、文件、Sockets等多種系統(tǒng)資源進行緩存和輸出。日志管理必須遵循幾個原則：1）級別輸出日志，定義一組標準的記錄級別，可用于控制記錄的輸出。可以把程序配置為只輸出某些級別的記錄，而忽略其他級別的輸出。2）提供多種輸出方式，包括內(nèi)存、數(shù)據(jù)庫、輸出流、控制臺、文件和套接字等。3）避免直接使用System.out.print來輸出日志。建議：通過封裝log4j來實現(xiàn)日志管理權限控制所有的權限控制都必須在控制層中進行，不能只在頁面中控制，這樣可以避免非法用戶通過URI來獲取或者操作數(shù)據(jù)，導致系統(tǒng)的不夠安全和健壯。4/8內(nèi)網(wǎng)J2EE架構需求說明書具體的權限控制實現(xiàn)必須使用權限體系提供的統(tǒng)一的權限控制，如下文描述。1,3?4?1權限控制實現(xiàn)判斷用戶是否擁有某個權限，只需要將權限的權限碼作為權限體系對外API的參數(shù)來調(diào)用該API即可。如判斷用戶是否擁有權限A（其權限碼是Acode），只需如下判斷語句:com.szhome.security.ext.SecurityExtApi.checkPermission（request,“Acode”）其中request為當前請求，返回true表示擁有權限，否則不擁有。這里的權限標識碼的命名非常重要，要讓程序員一看便知是哪個業(yè)務類別，哪個系統(tǒng)、哪個模塊、哪種操作。權限碼層次的表現(xiàn)方式如下：業(yè)務類別_應用名_模塊名_（2..n）級模塊名_操作名比如：p_hrms_employee_edit表示p（規(guī)劃）業(yè)務類別hrms（人事系統(tǒng)）應用的employee（人員）模塊的edit（編輯）操作，根據(jù)需要權限碼的層次可以增加相應的層數(shù)。應用項目組應該把應用的所有權限的權限碼放在一個或幾個類中，作為這些類的靜態(tài)屬性來維護。注：每個權限的權限碼需要權限管理員的審核和注冊，才能被使用。數(shù)據(jù)驗證包括前端的（客戶端）js的驗證和后端（服務器控制層端）的java驗證，對數(shù)據(jù)的驗證主要包括：1）數(shù)據(jù)格式（字符格式、日期格式、整型數(shù)字格式、浮點數(shù)格式等）是否正確。2）是否要區(qū)分大小寫。3、值是否為空。4、字符是否超長。盡可能在前端做好所有的數(shù)據(jù)合法性驗證，出現(xiàn)非法數(shù)據(jù)時在前端就能檢查出來，并給用戶友好的提示。在后端檢查出數(shù)據(jù)非法，并拋出異常提示對性能有一定的影響。如果前端和后端都沒有做數(shù)據(jù)合法性檢查，在持久層因為數(shù)據(jù)非法而拋出異常，代價將會更大。注意：對于安全較高或者在外網(wǎng)使用的程序，前端和后端的驗證都必須做，因為前端驗證很容易被繞過的,進而危機到程序的安全。對于在內(nèi)網(wǎng)使用的、安全性不是太高的程序可以只做前端的驗證。1.4MVC架構層次需求說明每一層都要履行該層對應的職責，視圖層不能實現(xiàn)控制層的功能，控制層不能實現(xiàn)模型層的功能等待，否則會造成各層之間的高耦合性，進而加大系統(tǒng)維護、移植的風險和成本。5/8內(nèi)網(wǎng)J2EE架構需求說明書V層（視圖層）主要包括jsp、html、圖片等，沒有任何業(yè)務邏輯。一般是從request中取得相應數(shù)據(jù)。該層主要負責：1）提供用戶請求的入口。2）客戶端的數(shù)據(jù)合法性驗證。3）顯示用戶請求的結果。C層（控制層）主要包括struts的action、Servlet等，只有控制邏輯，沒有任何業(yè)務邏輯。常見的誤用是在該層（例如，在Struts的ActionBean中）實現(xiàn)了所有的業(yè)務邏輯。使用該層的正確方法是調(diào)用適當?shù)臉I(yè)務層服務（或?qū)ο螅┎⒔Y果發(fā)送到視圖層（viewlayer）。該層主要負責：1）權限控制，首先判斷用戶是否登錄，然后判斷用戶是否有權限執(zhí)行該操作，如果沒有登錄或者無權操作提示相應的錯誤信息。2）服務器端的數(shù)據(jù)合法性驗證。3）處理請求數(shù)據(jù)的格式，將請求數(shù)據(jù)轉(zhuǎn)換成相應的DTO（數(shù)據(jù)傳輸對象）。4）調(diào)用業(yè)務代理，將DTO作為業(yè)務代理方法的參數(shù)來調(diào)用代理方法。5）重定向頁面，如果調(diào)用業(yè)務代理成功后，定向到指定頁面；否則定向到錯誤顯示頁面。1.4.3M層（模型層）主要包括javaBean、ejb、jms、jmail、代$、自己封裝的組件等，主要可以分為兩個子層：代理層、DAO層（持久層）。1?4,3.1代理層業(yè)務代理（BusinessDelegate），在Servlet和非servlet環(huán)境下都可以調(diào)用該層的方法，BusinessDelegate起到客戶端業(yè)務抽象化的作用。它抽象化，進而隱藏業(yè)務服務的實現(xiàn)。使用BusinessDelegate，可以降低表示層客戶端和系統(tǒng)的業(yè)務服務之間的耦合程度。根據(jù)實現(xiàn)策略不同，BusinessDelegate可以在業(yè)務服務API的實現(xiàn)中，保護客戶端不受可能的變動性影響。這樣，在業(yè)務服務API或其底層實現(xiàn)變化時，可以潛在地減少6/8內(nèi)網(wǎng)J2EE架構需求說明書必須修改表示層客戶端代碼的次數(shù)。該層一般沒有實際的業(yè)務邏輯、只是對業(yè)務邏輯做了一次包裝。通?？梢杂脕碚{(diào)用Ejb（主要是SessionBean），或者直接調(diào)用DAO。該層主要負責：1）封裝業(yè)務邏輯，方便控制層調(diào)用。將控制層和模型層的耦合降到最低。2）使業(yè)務邏輯脫離Servlet環(huán)境能正常運行。1?4.3.2DAO層（數(shù)據(jù)訪問層或持久層）該層實現(xiàn)主要的業(yè)務邏輯，并與持久性數(shù)據(jù)（數(shù)據(jù)庫、xml文件、word或excel文檔等）交互。持久層的常用操作（如：增加、修改、查找、刪除、生成列表等）可以封裝在以個通用的DAO中，實際業(yè)務實現(xiàn)的時候只需要繼承這個通用DAO就可以實現(xiàn)常用的業(yè)務功能。該層主要負責：1）處理業(yè)務邏輯。2）業(yè)務權限判斷3）操作數(shù)據(jù)庫或文件（如：增加、修改、查找、刪除）。4）事務處理。DAO層必須滿足以下四個標準：一、具有透明性業(yè)務對象在不知道數(shù)據(jù)源實現(xiàn)的具體細節(jié)情況下，可以使用數(shù)據(jù)源。由于實現(xiàn)細節(jié)隱藏在數(shù)據(jù)訪問層的內(nèi)部，所以訪問是透明的。二、易于遷移數(shù)據(jù)訪問層使應用程序很容易遷移到其他數(shù)據(jù)庫實現(xiàn)。業(yè)務對象不了解底層的數(shù)據(jù)實現(xiàn)，所以遷移僅僅涉及到修改數(shù)據(jù)訪問層。進一步地說，如果您正在部署某種工廠策略，您可以為每個底層的存儲實現(xiàn)提供具體的工廠實現(xiàn)。如果是那樣的話，遷移到不同的存儲實現(xiàn)意味著為應用程序提供一個新的工廠實現(xiàn)。三、盡量減少業(yè)務對象中代碼復雜性因為數(shù)據(jù)訪問層管理著所有的數(shù)據(jù)訪問復雜性，所以它可以簡化業(yè)務對象和使用數(shù)據(jù)訪問層的其他數(shù)據(jù)客戶端的代碼。數(shù)據(jù)訪問層，而不是業(yè)務對象，含有許多與實現(xiàn)相關的代碼（例如SQL語句）。這樣給開發(fā)人員帶來了更高的效率、更好的可維護性、提高了代碼的可讀性等一系列好處。四、把所有的數(shù)據(jù)訪問集中在單獨的層上由于所有的數(shù)據(jù)訪問操作現(xiàn)在都委托給數(shù)據(jù)訪問層，所以您可以將這個單獨的數(shù)據(jù)訪問層看做能夠?qū)贸绦虻钠渌糠峙c數(shù)據(jù)訪問實現(xiàn)相互隔離的層。這種集中化可以使應7/8內(nèi)網(wǎng)J2EE架構需求說明書用程序易于