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

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

簡單來說就是看情況。

主要看你項目：

• 變動情況
• 以及架構(gòu)
• 人員
• 項目情況

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

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

再來，如果項目組新手較多，可能簡單的代碼結(jié)構(gòu)更適合。復(fù)雜項目結(jié)構(gòu)的學(xué)習(xí)成本要高。

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

可以用經(jīng)濟學(xué)上的成本來解釋原因。

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

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

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

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

service調(diào)用是使用service還是調(diào)用dao層？

　　都可以，根據(jù)比較嚴(yán)謹(jǐn)?shù)木幋a規(guī)范，應(yīng)該是自己的Service，調(diào)用自己的Dao

　　例如：用戶管理，UserService調(diào)用UserDao ， 角色管理：RoleService，調(diào)用RoleDao，

　　如果在用戶管理的過程中，設(shè)置權(quán)限，那么應(yīng)該是UserService調(diào)用RoleService方法進(jìn)行角色的設(shè)置，然后調(diào)用UserDao進(jìn)行用戶的設(shè)置。

java調(diào)用其他模塊，是放在control層通過service接口調(diào)用好，還是放在service層通過dao的接口調(diào)用好？

個人建議調(diào)用其他模塊的接口，建議通過service層調(diào)用。如果A模塊的service調(diào)用B模塊的dao，B模塊的dao和A模塊耦合。假設(shè)隨著業(yè)務(wù)的發(fā)展，需要將A、B模塊各自單獨發(fā)布成一個服務(wù)，那么A、B模塊都要維護B模塊的dao，并且A、B模塊的開發(fā)人員都要熟悉B模塊的dao，B模塊的表增減字段后，需要同時通知A、B模塊的開發(fā)人員，顯然不便于維護。而且由于A、B模塊都引入了B的dao模塊，意味著A模塊可以直接訪問B模塊dao的所有功能，而dao模塊通常是一些基礎(chǔ)操作。反之，service層一般是有具體業(yè)務(wù)含義的，通過service對外暴露具有特定含義的業(yè)務(wù)接口，可以避免將底層的操作全部暴露給外部模塊。再假設(shè)隨著業(yè)務(wù)的進(jìn)一步發(fā)展，A、B模塊需要進(jìn)行分庫，A、B模塊分別使用各自的數(shù)據(jù)庫，那么A再引入B的dao則必須訪問B的數(shù)據(jù)庫，意味著A要訪問A、B兩個模塊的數(shù)據(jù)庫，如果還有C、D模塊呢，則A要訪問A、B、C、D多各模塊的數(shù)據(jù)庫，顯然不利于開發(fā)和維護，也不利于被引用模塊的數(shù)據(jù)安全。

service層怎么調(diào)用dao層？

一般的做法是service的代碼這注入dao@Autowiredprivate AuditDao auditDaopublic AuditDao getAuditDao() {return this.auditDao}可以通過auditDao.調(diào)用方法

java業(yè)務(wù)邏輯，寫在哪里比較好？

現(xiàn)在很多公司開發(fā)人員應(yīng)該采用都是mvc架構(gòu)。

Mvc就是所謂的model模型，view視圖，controller控制器。

每個層都有明確分工。

簡單的項目拋開nignx，網(wǎng)關(guān)，一般都是前端發(fā)一個請求到后端，首先到達(dá)contoller然后是service層再然后是dao層。

這里的service層就是所謂的業(yè)務(wù)層，專門負(fù)責(zé)業(yè)務(wù)處理操作，而dao層負(fù)責(zé)和數(shù)據(jù)庫打交道，從db拿數(shù)據(jù)返給service，sevice處理完返給controller層，controller通過視圖解析器，解析完通過瀏覽器渲染頁面。

說到這里基本上，我想答案已經(jīng)很明顯了。那就是Java業(yè)務(wù)邏輯寫在service層。

而sevice層其實又涉及到接口和接口實現(xiàn)。

就是我們一般寫代碼都會定義一個接口供controller去調(diào)用。

其實service接口的實現(xiàn)類最終才應(yīng)該是寫業(yè)務(wù)邏輯的地方。

當(dāng)然很多公司可能不止一個sevice層，比如還有一個manager層繼續(xù)對數(shù)據(jù)做特殊業(yè)務(wù)處理，這里只是簡單的說下大致情況。

每個公司每個項目根據(jù)自身業(yè)務(wù)，架構(gòu)可能不太一樣。但本質(zhì)是一樣的。

總結(jié)一下就是業(yè)務(wù)邏輯肯定需要單獨作為一層去處理，這樣既方便拓展，也方便維護。切記不要把所有的業(yè)務(wù)邏輯都寫在controller里面。

每個層都有自己的分工，都揉在一塊不僅僅代碼冗長看起來還很亂，不清晰。

好了，希望我的回答能幫到你！

感興趣可以關(guān)注，共同學(xué)習(xí)交流！