【部分轉載】

1、java web 中dao 層和service層都使用介面，是否是為使用介面而使用介面？

一個dao或者一個service都是一個介面，然後再一個類去實現，為什麼不直接使用一個類呢？在入門級（單表）的SSM+maven程式碼裡面，我們甚至可以看到dao和service的介面類中程式碼內容都是一樣的，這個作何理解？

java web中的三層架構：

其中，表示層一般是採用 MVC 架構模式，業務層有事務指令碼模式、領域模型模式等，持久層有資料對映器模式（Hibernate即是典型的）、入口模式（MyBatis、JDBC）。企業應用中最關鍵的顯然是業務層。而對於初學者來說，事務指令碼模式是最為簡單，最容易掌握的。如果開發團隊面向物件設計能力一般，而且業務邏輯相對簡單，業務層一般都會採用事務指令碼模式。

所謂事務指令碼模式，就是將業務層的物件分為三類，按照下圖的方式組織起來（下圖是用EA畫的UML類圖，一個簡單的學生管理的業務層設計）。

如上圖所示，在事務指令碼模式中，有三類物件。其中，Service類封裝業務流程（或者說是介面上的業務流程），DAO類封裝對持久層的訪問，DTO類封裝業務實體物件。各個物件之間的關係如上圖所示，這就是所謂業務邏輯的組織方式。

為什麼要用Service介面和DAO介面？
其實就是為了解耦，解耦說的意思是你更改某一層程式碼，不會影響我其他層程式碼，如果你會像spring這樣的框架，你會了解面向介面程式設計，表示層呼叫控制層，控制層呼叫業務層，業務層呼叫資料訪問層。舉個例子，用DAO介面，那麼持久層用Hibernate，還是用myBatis，還是 JDBC，隨時可以替換，不用修改業務層Service類的程式碼。

具體來講：標準主流現在的表現層都是採用MVC綜合設計模式，最終目的達到解耦， 初期也許都是new物件去呼叫下一層，比如你在業務層new一個DAO類的物件，呼叫DAO類方法訪問資料庫，這樣寫是不對的，因為在業務層中是不應該含有具體物件，最多隻能有引用，如果有具體物件存在，就耦合了。 當那個物件不存在，我還要修改業務的程式碼，這不符合邏輯。好比主機板上記憶體壞了，我換記憶體，沒必要連主機板一起換。我不用知道記憶體是哪家生產，不用知道多大容量，只要是記憶體都可以插上這個介面使用。這就是MVC的意義。 
其實因為入門級程式做東西分層次不是那麼嚴格，涉及到的業務很少，舉個最簡單的例子，你做一個分頁的功能，資料1000條，你20條在一個頁，你可以把這個功能寫成工具類封裝起來，然後在業務層裡呼叫這個封裝的方法，這才是業務裡真正幹得事，只要沒訪問資料庫的，都要在業務裡寫。 
DAO一定是和資料庫的每張表一一對應，而service則不是。專案中一個service和一個DAO其實也一樣可以操作資料庫，只不過那要是表非常多，出問題了，那找起來多麻煩，而且太亂了。

一個DAO單獨對1個表進行操作。一個Service可以操作幾個DAO。

構建業務層的模式：Service + DAO,即DAO中只做CRUD及類似的簡單操作(稱之為功能點,不包含業務邏輯),Service中通過呼叫一個或多個DAO中的功能點來組合成為業務邏輯.Service的數量應該由功能模組來決定。在這種模型中業務邏輯是放在Service中的,事務的邊界也應該在Service中控制. 當然,直接在Service中控制事務會引入非業務邏輯的程式碼,幸好spring的AOP可以解決這個問題,這也是引入Spring的原因之一。如果說到缺點,就在於對某些物件的操作就是簡單的CRUD，Service層顯得累贅。

2、java web中的service，dao，po分別是什麼意思和什麼作用

Service:service層是在mcv三層模式中新新增一層，能夠更加清晰的定義應用程式的邊界，需要操作資料的時候，通過service層訪問DAO層來實現。service層做的事情，不僅僅是呼叫DAO操作資料，還會包含了一定的業務邏輯。整個程式設計就變成了針對服務的設計。
DAO：Data Access Object是一個數據訪問介面，資料訪問：顧名思義就是與資料庫打交道。夾在業務邏輯與資料庫資源中間。是MVC模式中Model層

PO：Persistent Object即持久物件，它們是由一組屬性和屬性的get和set方法組成。可以看成是與資料庫中的表相對映的java物件

Dao主要做資料庫的互動工作
Modle 是模型 存放你的實體類
Service 做相應的業務邏輯處理
Action是一個控制器
Action像是服務員，顧客點什麼菜，菜上給幾號桌，都是ta的職責；Service是廚師，action送來的選單上的菜全是ta做的；Dao是廚房的小工，和原材料(通過mybatis操作資料庫)打交道的事情全是ta管。物件的呼叫流程：JSP—Action—Service—DAO—mybatis—資料庫。

3、service層事物控制的理解

一般情況下，我們會把事務控制在service層。

例如我們的一個業務：刪除A記錄，插入B記錄（需要在一個事務裡進行），如果我們把這個業務邏輯寫在了action層，我們再action層呼叫刪除A的service，然後再呼叫插入B的service，如果說插入B失敗了，那我們刪除A這個操作將不能回滾，因為事務控制在了service層，這樣寫已不是一個事務。刪除A操作的service已經完成，事務已經提交了，插入B的操作在另外的事務裡執行。根據需要，業務邏輯儘量放在service層。通過配置spring事務控制的傳播行為，在service層可以達到大部分的業務事務要求，而不需另加一層。spring的事務有兩種一種是宣告式事務，一種是程式設計式事務。

action和dao層，會使用一些框架技術。比如action層可能選擇有springmvc、struts等，dao層有hibernate、mybatis等選擇，所以action的dao有可能根據情況變化，而service層關注業務邏輯，業務程式碼都是自己完成的，程式碼對自己是透明的。

我們更應該把與業務相關的程式碼移至service層控制事務。這主要發生在我們把整個業務邏輯放在了service的一個方法，而這個方法以及呼叫的方法的事務配置為required（或其他），但業務的部分操作需要在不同的事務中進行，我們不想寫另外的方法，也不想去更改事務配置，所以引入support層（或許你說可以把這種邏輯向action層移動，在action層處理，但記住我們的前提，action的框架是會變的，我們想盡量做到更改action層時，更簡單。而且從分工來說，action層應該只關注檢視邏輯，個人自掃門前雪，休管他人瓦上霜）。support層當然不是隻為處理這種事務問題的，我把它定義為業務處理時需要的一些輔助層，可以協助處理業務，比如剛才說的事務問題，還有可以提供工具類支援等。 

對於dao層，應該只關注資料庫連線執行結果封裝這些事。

實際程式碼參照：https://blog.csdn.net/acweilisky0825/article/details/52032867