學(xué)習(xí)Java的人對其三大框架都不會陌生，這三大框架也就是Struts+Hibernate+Spring，主要用來做Web應(yīng)用。但是在初學(xué)者看來，它們也被賦予了太多神秘的色彩，究竟要不要重點學(xué)還是存在很多的爭議。

　　一、spring

　　我們知道企業(yè)開發(fā)面臨著一個讓所有程序員都非常頭疼的問題，那就是需求的不斷變動，導(dǎo)致系統(tǒng)不停的修改。其中接口可以一定成度的解決服務(wù)間耦合度過高的問題，但是依然無法完全解耦。就比如說一個類A依賴于服務(wù)S，S的服務(wù)實現(xiàn)有s1，那么在A類中使用服務(wù)S時必然會有news1的操作，這就出現(xiàn)了強耦合，假如S的服務(wù)實現(xiàn)有變化，需要改為s2，這個時候就需要修改類A里面的代碼，這明顯是不合理的。為什么不合理可以舉個例子：電腦使用U盤1存儲數(shù)據(jù)和使用U盤2存儲數(shù)據(jù)，在更換不同的U盤時是不需要修改電腦硬件的。為了解決這個強耦合問題，spring出現(xiàn)了，spring通過XML配置文件來描述類之間的依賴關(guān)系，這里面配置文件只有類名之間的關(guān)系，運行時是需要創(chuàng)建類的實例的，所以spring是基于反射機制的。使用spring之后之前的問題中，類A就不會再去new服務(wù)S的實現(xiàn)了，而是將類A依賴的服務(wù)配置到XML中，由spring去管理類之間的依賴（由人控制轉(zhuǎn)為系統(tǒng)控制，這也就是為什么說spring的技術(shù)核心是控制反轉(zhuǎn)），這樣之前的問題就完美解決了，服務(wù)S的實現(xiàn)變更了無非就是修改XML配置文件罷了，不需要到處去找new了s1的類。由于類A依賴的服務(wù)S的實現(xiàn)由spring控制，這樣就可以做一些比較有趣的事情，比如說AOP，spring完全可以在獲取s1的實例的時候生成s1類實例的代理類（通過ASM或CGLIB或著依賴于ASM的javassist或著java自帶的動態(tài)代理），這樣就可以實現(xiàn)對s1的方法級的調(diào)用“攔截”。因為spring的這種強大的解耦性，所以spring可以和任何一個框架進行完美集成。

　　二、Hibernate（我這里簡稱H）

　　java里面一切都是對象，在和數(shù)據(jù)庫打交道時就不是那么“對象”了，往往數(shù)據(jù)庫中的table和java里面的entity是有一個對應(yīng)關(guān)系的，但是在將java的一個entity保存到數(shù)據(jù)庫對應(yīng)的表，這就需要一個將entity轉(zhuǎn)換成sql的過程，這個過程是很繁雜而且易出錯，于是有了Hibernate，使用H保存數(shù)據(jù)變得如此容易，H通過配置文件來描述類和表的映射關(guān)系，連類里面那種多對多和一對多等等關(guān)系都可以實現(xiàn)自動生成對多表的更新操作。但是H在做數(shù)據(jù)查詢時就不是那么愉快了，往往我們只需要查詢幾個字段的時候，H查出來的會是一大坨的數(shù)據(jù)，所以H不是特別適合做企業(yè)項目，但是H非常適合做不同數(shù)據(jù)庫間的同步。

　　三、struts

　　早起ajax技術(shù)沒有出現(xiàn)的時候，前端向后臺提交數(shù)據(jù)都是通過表單的，表單和java對象的互相轉(zhuǎn)換問題也讓很多程序員頭疼不已，struts的出現(xiàn)解決了表單和java對象的互相轉(zhuǎn)換問題，還有前端jsp的頁面布局問題，訪問等。在springmvc沒有出現(xiàn)之前SSH算是一個比較完美的框架組合，但是由于H的坑，很多人轉(zhuǎn)向了SSM，或者直接就是Springmvc+mybatis。

　   以上就是動力節(jié)點Java培訓(xùn)機構(gòu)小編介紹的“Java三大框架視頻教程下載”的內(nèi)容，希望對大家有幫助，如有疑問，請在線咨詢，有專業(yè)老師隨時為你服務(wù)。