對于一個軟件公司而言，在做項目或產品的過程中，為何要應用一定的技術框架呢？相信有一定規模一定歷史積淀的軟件公司里，都存在著自己特有的技術框架，我們應用框架開發無外乎是本著提高代碼的重用性、降低開發應用模塊的技術難度，增強軟件的維護性，進爾達到提高工作效率、降低生產成本的目的。這也是技術框架存在的根本和意義所在。

本人是個對技術的推崇者或者說是有些圖騰崇拜的人，從學習和使用 java 的第一天開始，就對這種純粹的面向對象的編程語言產生了濃厚的興趣，從早期秉燭夜讀《 java 編程思想》、《 java 核心技術卷 I 、卷 II 》到《 J2EE 設計與模式》。。。《深入淺出 Hibernate 》。。。《 Spring in Action 》等，切身感受到當今主流 java 應用技術的發展，也很感謝前輩們為大家開創了應用技術之先河，為我輩指明了發展的方向和前進的道路。

在當今技術潮流日新月異的時代各種各樣的技術框架林林總總，很難去評價個中孰優孰劣，個人覺得在項目開發過程中最適合的框架就是最好的，以項目的規模和特點來決定對技術框架的選型。現就個人對于框架的開發的一些體會和大家一起交流一下，前端采用類 Struts 模式做 MVC, 我覺得 MVC 的精華所在就在于請求的匯集和請求的分發，采用 filter+mainservlet 的方式，在 filter 類中可以進行對各種請求的約束和限制處理，同時可以進行對請求合法性的判定和校驗，也可以實現達到負載均衡的處理，也可以根據實際的項目需要設置多個 filter 類進行分類過濾。通過 filter 類的合法的請求全部由統一的 mainservlet 主控器接口進行分發處理，在這里可以添加對線程的約束和控制，以保證所有請求可以順利的分發。業務邏輯層采用 Action+BPO 的模式， Action 作為動作的描述， BPO 作為對于動作進行響應的業務邏輯處理。持久層部分采用 Hibernate 和 DAO+VO 兩種模式并存的方式，持久層部分之所以采用兩種模式處理，主要是考慮到業務邏輯的復雜度，對于多表及連和復雜的業務查詢處理，感覺配置 Hibernate 文件也相當的復雜（也許是本人應用 Hibernate 的深度還不夠，對 HQL 語言的認識還比較膚淺），因而還采取傳統的 jdbc 訪問模式來處理。事務處理用 Spring 框架來進行處理。在表示層的 jsp 中只進行 tag 的屬性設置和 java 的表達式的輸出，所有的 java 邏輯代碼全部用 tag 來進行封裝。有興趣的朋友可以發 e-mail 給我，來進行此框架的交流 E-mail:syangsheep@163.com, 同時也歡迎大家拿出自己應用的框架來一起進行交流和探討。