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

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

簡(jiǎn)單來(lái)說(shuō)就是看情況。

主要看你項(xiàng)目：

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

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

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

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

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

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

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

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

如果項(xiàng)目變動(dòng)多、模塊部署、項(xiàng)目不急，那使用接口的成本就低于不使用接口的成本，雖然早期可能不用接口看起來(lái)更簡(jiǎn)單；反之，則不用接口的成本低，甚至框架都可以不使用～

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

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，

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

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

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

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

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

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

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

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

每個(gè)層都有明確分工。

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

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

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

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

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

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

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

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

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

每個(gè)層都有自己的分工，都揉在一塊不僅僅代碼冗長(zhǎng)看起來(lái)還很亂，不清晰。

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

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