內網J2EE架構需求說明書1架構需求說明總體架構圖V層（視圖層）：包括jsp

、html等，該層只負責顯

示數據的功能，沒有任何

業務邏輯。一般是從requ

est中取得相應數據。C層（控制層）：包括struts

的action、Servlet等，該層

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

數據、調用業務代理、重

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