閒談“如何優化SSH框架的項目”

使用struts框架的好處之一就是所有action類繼承一個基類,將訪問控制在基類中處理.2.所有的action類都繼承自baseaction,一個資源對應一個action類.
1.實現一個繼承自struts的action的baseaction.從action類名提取資源名稱,在mapping中的parameter提取當前action做爲opertion.將userid,resource,operation作爲參數傳遞到權限驗證接口進行驗證.參考struts的dispatchaction使用反射機制調用請求的方法. 在處理一個業務事務中,需要的不止一個action方法,例如修改資源這個業務過程,它需要兩個ation,一個是顯示資源信息進行編輯的方法edit,一個是將編輯好後的資源信息提交到服務器進行持久化操作的方法update.這樣就是業務方法與action方法不對應.這裏我們不需要對edit這個方法進行訪問控制,需要控制的是update方法.並且在進行權限指派中也不需要edit這個權限.個人認爲，Struts在Model層的東西太少了或是說幾乎沒有涉及。

Spring的核心是Ioc模式(又稱DI：Dependency Injection)實現的Bean工廠(BeanFactory)和AOP(Aspect Oriented Programming)，我們可以用Struts+Spring，將兩者結合可以將其自身的特點互補。完成我們要做的工作。

一、Hibernate是JDBC的輕量級的對象封裝，它是一個獨立的對象持久層框架，和App Server，和EJB沒有什麼必然的聯繫。Hibernate可以用在任何JDBC可以使用的場合，例如Java應用程序的數據庫訪問代碼，DAO接口的實現類，甚至可以是BMP裏面的訪問數據庫的代碼。從這個意義上來說，Hibernate和EB不是一個範疇的東西，也不存在非此即彼的關係。 
二、Hibernate是一個和JDBC密切關聯的框架，所以Hibernate的兼容性和JDBC驅動，和數據庫都有一定的關係，但是和使用它的Java程序，和App Server沒有任何關係，也不存在兼容性問題。 
三、Hibernate不能用來直接和Entity Bean做對比，只有放在整個J2EE項目的框架中才能比較。並且即使是放在軟件整體框架中來看，Hibernate也是做爲JDBC的替代者出現的，而不是Entity Bean的替代者出現的，讓我再列一次我已經列n次的框架結構： 傳統的架構：
 1) Session Bean <-> Entity Bean <-> DB 爲了解決性能障礙的替代架構：
 2) Session Bean <-> DAO <-> JDBC <-> DB 使用Hibernate來提高上面架構的開發效率的架構： 
 3) Session Bean <-> DAO <-> Hibernate <-> DB 就上面3個架構來分析：
  1、內存消耗：採用JDBC的架構2無疑是最省內存的，Hibernate的架構3次之，EB的架構1最差。  
  2、運行效率：如果JDBC的代碼寫的非常優化，那麼JDBC架構運行效率最高，但是實際項目中，這一點幾乎做不到，這需要程序員非常精通JDBC，運用Batch語句，調整PreapredStatement的Batch Size和Fetch Size等參數，以及在必要的情況下采用結果集cache等等。而一般情況下程序員是做不到這一點的。因此Hibernate架構表現出最快的運行效率。EB的架構效率會差的很遠。  
  3、開發效率：在有JBuilder的支持下以及簡單的項目，EB架構開發效率最高，JDBC次之，Hibernate最差。但是在大的項目，特別是持久層關係映射很複雜的情況下，Hibernate效率高的驚人，JDBC次之，而EB架構很可能會失敗。 
  4、分佈式，安全檢查，集羣，負載均衡的支持 由於有SB做爲Facade，3個架構沒有區別。 四、EB和Hibernate學習難度在哪裏？ EB的難度在哪裏？不在複雜的XML配置文件上，而在於EB運用稍微不慎，就有嚴重的性能障礙。所以難在你需要學習很多EJB設計模式來避開性能問題，需要學習App Server和EB的配置來優化EB的運行效率。做EB的開發工作，程序員的大部分精力都被放到了EB的性能問題上了，反而沒有更多的精力關注本身就主要投入精力去考慮的對象持久層的設計上來。 Hibernate難在哪裏？不在Hibernate本身的複雜，實際上Hibernate非常的簡單，難在Hibernate太靈活了。 當你用EB來實現持久層的時候，你會發現EB實在是太笨拙了，笨拙到你根本沒有什麼可以選擇的餘地，所以你根本就不用花費精力去設計方案，去平衡方案的好壞，去費腦筋考慮選擇哪個方案，因爲只有唯一的方案擺在你面前，你只能這麼做，沒得選擇。 Hibernate相反，它太靈活了，相同的問題，你至少可以設計出十幾種方案來解決，所以特別的犯難，究竟用這個，還是用那個呢？這些方案之間到底有什麼區別呢？他們的運行原理有什麼不同？運行效率哪個比較好？光是主鍵生成，就有七八種方案供你選擇，你爲難不爲難？集合屬性可以用Set，可以用List，還可以用Bag，到底哪個效率高，你爲難不爲難？查詢可以用iterator，可以用list，哪個好，有什麼區別？你爲難不爲難？複合主鍵你可以直接在hbm裏面配置，也可以自定義CustomerType，哪種比較好些？你爲難不爲難？對於一個表，你可以選擇單一映射一個對象，也可以映射成父子對象，還可以映射成兩個1:1的對象，在什麼情況下用哪種方案比較好，你爲難不爲難？ 這個列表可以一直開列下去，直到你不想再看下去爲止。當你面前擺着無數的眼花繚亂的方案的時候，你會覺得幸福呢？還是悲哀呢？如果你是一個負責的程序員，那麼你一定會仔細研究每種方案的區別，每種方案的效率，每種方案的適用場合，你會覺得你已經陷入進去拔不出來了。如果是用EB，你第一秒種就已經做出了決定，根本沒得選擇，比如說集合屬性，你只能用Collection，如果是Hibernate，你會在Bag，List和Set之間來回猶豫不決，甚至搞不清楚的話，程序都沒有辦法寫。