Service層和Dao層真的有必要每個類都加上接口嗎？簡單來說就是看情況。主要看你項目：變動情況以及架構人員項目情況比如，項目原來使用的hibernate，后續(xù)可能要切換為mybatis，那么dao

Service層和Dao層真的有必要每個類都加上接口嗎？

簡單來說就是看情況。

主要看你項目：

• 變動情況
• 以及架構
• 人員
• 項目情況

比如，項目原來使用的hibernate，后續(xù)可能要切換為mybatis，那么dao就需要使用接口。這就不會影響上層代碼的修改。

再比如，項目是個單體應用，任何代碼的修改都需要重新編譯整個項目，那可以不用接口。而如果項目是分模塊編譯部署的，那就可以使用接口解耦，假設dao有修改，只需要重新編譯部署dao模塊即可，不影響上層模塊。

再來，如果項目組新手較多，可能簡單的代碼結構更適合。復雜項目結構的學習成本要高。

假如，項目進度很急，可以使用簡單粗暴的方式先擼～

可以用經濟學上的成本來解釋原因。

經濟學上的成本定義是：你做一件事，所放棄的其它事情中，價值最大的那件事的價值就是你做這件事的成本。

你使用接口的成本就是你不使用接口所花費的成本（包括后續(xù)的維護成本）。

如果項目變動多、模塊部署、項目不急，那使用接口的成本就低于不使用接口的成本，雖然早期可能不用接口看起來更簡單；反之，則不用接口的成本低，甚至框架都可以不使用～

畢竟工具是為了提高效率的，何必和自己過不去呢！

如何領悟Java三大框架？

Hibernate:

Hibernate主要就是ORM(對象關系映射)由框架 配置文件實現(xiàn)的。讓實體類和數(shù)據(jù)庫表進行一一對應關系。讓實體類先和數(shù)據(jù)庫表對應，讓實體類屬性和數(shù)據(jù)庫表中字段一一對應。這樣就不需要操作數(shù)據(jù)庫表，而操作表中對應的實體類對象。以此來實現(xiàn)對應的增刪改查操作。

同樣對于dao層的框架還有Mybatis，Mybatis不是一個完全的ORM框架，MyBatis的sql需要開發(fā)人員自己編寫，但同時提供了輸入和輸出的自動映射，所以可以認為是半自動的ORM框架。Mybatis可以通過XML或注解方式靈活配置要運行的sql語句，并將java對象和sql語句映射生成最終執(zhí)行的sql，最后將sql執(zhí)行的結果再映射生成java對象，對于不斷變更的客戶需求更加靈活。但是靈活的前提是Mybatis無法做到數(shù)據(jù)庫無關性，如果需要實現(xiàn)支持多種數(shù)據(jù)庫的軟件則需要自定義多套sql映射文件，工作量大。而Hibernate對象關系映射能力強，數(shù)據(jù)庫無關性好。

Struts2：

Struts2處理請求是為每個請求都創(chuàng)建一個單獨的Action類，Action類當中的Field屬性參數(shù)作為輸入和輸出參數(shù)用IOC來依賴注入的方式，是基于類的開發(fā)。

同樣的SpringMVC則采用輸入Request和Reponse作為參數(shù)，返回ModelAndView的方式，是單例的模式，且是基于方法的模式。

spring:

Spring最核心的概念就是DI（依賴注入）和AOP（面向切面編程），DI也稱為IoC（控制反轉）。有了Spring之后，通過IOC，所有的對象都可以從Spring容器中得到。每個對象由Spring注入到對應的地方。通過IoC先由Spring創(chuàng)建對象后，才能進行下一步對象注入（DI），所以說DI依賴IOC。