封層架構可能會導致修改代碼的時候，對某一個變量的修改，可能涉及到所有的關係到這個變量的層次都需要進行修改，下面是小編蒐集整理的一篇探究軟件開發框架技術的論文範文，供大家閱讀參考。
摘要：框架技術對於軟件開發來說，意義重大，不僅可以簡化開發流程，更利於後期維護。本文就軟件開發中的框架技術進行分析，重點探討struts、hibernate、spring以及分層架構內容。
關鍵詞：框架技術 分層架構 軟件開發
1、SSH框架技術
SSH技術即struts、hibernate、spring技術的縮寫，是當前比較流行的開源框架技術。
1.1 struts技術
Struts這個名字最初是金屬架的意思。開發者希望通過Struts這個框架技術支持JSP、Servlet、Java，然後在Web系統項目中的使用這門技術。
2001年春天，在apache的網站上發佈Struts的第一個版本的時候，Struts技術只提供了一種將視圖和業務邏輯分離的Web應用方案。當Struts這種Web應用技術出現的時候，每個開發人員都把它視爲一種利器，把自己從繁忙的工作中解脫出來。所以在2001-2003這兩年的時間裏，大量IT公司在系統開發的過程中Struts技術作爲框架。
Struts的一大優點是它是開源軟件[6]。Struts 本質是在Model2的基礎上實現的一個MVC架構，採用的主要技術是Servlet、JSP和custom tag library用戶自定義標記庫[7]。Struts是運用MVC的體系編寫的一個Web應用的一個框架, 可以說是一個傳統MVC設計模式的一種改進類型。
1.2 hibernate技術
在Java世界裏，Hibernate一直是最引人關注的一個話題。從Gavin King加入EJB3.0 EG，負責制訂EJB3.0的持久層規範;到Gavin King非正式退出JDO EG，並且充滿個人情緒的對JDO2.0規範進行攻擊;到《Hibernate in Action》的發行;再後來到Hibernate3 Alpha的發佈;最後再到JBoss 3.0 PR的發佈。Hibernate在短短不到3年的時間內，從一個名不見經傳的開源軟件發展成到今天令業界矚目的主流的O/R Mapping框架技術，在當前的Java持久層框架中，最流行的O/R Mapping的產品分別是Hibernate，JDO以及TopLink。而Hibernate往往就是項目開發的首選, Hibernate的輕量級ORM模型逐步確立了在Java對象關係映射架構中的地位，而且它的許多設計還被Java EE標註組織吸納成爲EJB3.0規範的標準。
1.3 spring技術
Spring技術起源於2000年，它是Rod Johnson通過一些成功的商業項目構建起來的基礎框架技術。在2002，Rod Johnson發佈了《Expert One-on-One J2EE Design and Development》一書，並伴隨着書的發佈，同時提供了一個初步的開發框架技術，interface21開發包，interface21也就是書中闡述的內容的具體實現。後來，Rod Johnson 在interface21開發包的基礎之上，進行了進一步的改造和擴充，使其發展爲一個更加開放、清晰、全面、高效的開發框架——Spring。2003年2月，Spring框架技術正式成爲一個開源項目，開始發佈。Spring是一個解決了許多在J2EE開發中常見問題的強大框架。
2、分層架構
分層架構具有顯著地特點，系統最高級別的目標功能位於最頂層，具體的涉及到跨領域的業務功能在中間層，系統配置以及系統環境位於底層。上一層調用下一層的數據，下一層爲上一層提供服務。分層架構要遵循一定的原則:(1)可見度原則。每個系統的依賴關係只存在以同一級別的層次或者是下一個級別的子系統。(2)易變性原則。易變性原則也適合具體的層次相關聯的，越往上的層次越靠近用戶的需求，由於用戶的需求是異變的，因此這一層次的抽象也往往最容易發生變化，而底層的數據庫連接、環境配置、硬件驅動等等，這些相對來說不容易變化的，即使頂層的需求變化，這一部分是向上提供服務的，相對不易變化。(3)通用性原則。抽象模型元素一般放在放置在分層架構的底層。如果這些不涉及或者是不專注於具體的實現，則可以將這邪惡放在中間層次;(4)層數。對已通常的系統來說，三層是比較普遍的，對已特別複雜的系統，要加入層次，隨着層數的增加，複雜性也會增加。
使用分層架構，有如下幾方面的優點：(1)每一層的設計只關注本層次。在進行系統開發的時候，業務功能的層次只需負責具體需求的`實現，數據庫持久的層次只關注與數據庫的連接與管理，不需要對其他層次進行考慮。(2)開發更加方便。在系統開發中，很可能會遇到功能類似的系統，那麼實現系統時這兩個功能的實現會很容易，只需將涉及到功能的名字和變量進行替換就可以完成系統功能。(3)降低耦合。分層可以降低系統之間的依賴。例如，web表示層只需要關注與怎麼對外提供服務，至於中間的業務邏輯層是怎樣流轉的，數據庫持久層怎麼進行數據提供，都不需要關心，這樣充分降低了系統之間的耦合。(4)代碼複用。某一層次的實現，可以像其他很多層次提供服務。 (5)可以使代碼編寫更加整潔，利於標準化工作。
分層架構也存在有一些弊端和缺點：(1)數據級聯。封層架構可能會導致修改代碼的時候，對某一個變量的修改，可能涉及到所有的關係到這個變量的層次都需要進行修改。(2)分層架構的層次要適度。對於系統來說，並不是越多的層次對系統越好，系統越多，系統開銷越大，系統負擔也越大，系統開發難度也越大，對已普通的應用性系統來說，如果需求不是特別多，數據量非海量型的，那麼三層架構已經可以實現，對已數據量大，業務需求複雜的系統，可以分爲4-5個層次，對已5層以上的分層不提倡，這樣分層的話，會使本來先對比較簡單的工作變得複雜，反而會不利於系統的開發和後期的維護工作。
通過以上幾點分析，分層對系統來說是有利有弊的，適當的分層架構對系統很重要，要進行權衡利弊，並不是越多的層次越好，分層的具體要根據實際的需求進行聯繫，進行細緻的分析和考慮，這樣才能使開發更有效率，維護也更加方便。
參考文獻
[1]李海濤設計模式在JSP開發中的應用[J].電腦編程技巧與維護,2011,(10).