混合DAO和服務調用

假設我們在服務層上面有一些層，例如Web控制器。服務層依次位於DAO/Repo層之上。在上層，服務呼叫與回購呼叫一起使用。它在一定程度上打破了應用程序的分層，但是我們真的應該把包裝回購方法如findAll()納入服務方法。我不這麼認爲。由於這種設計，是否有任何缺點可能導致很多痛苦？交易問題？混合DAO和服務調用

來源

2015-04-29 yuranos87

我會把你的問題轉過來說 - 爲什麼沒有這樣一個方法的服務層？它是這樣的包像一個DAO方法的疼痛：

public class PersonService { 
... 
    private PersonDao personDao; 
... 
    public List<Person> findAll() { 
     return personDao.findAll(); 
    } 
... 
}

客戶數據 如果你不想發回代表一個人的控制器的數據實體？您可以將服務層中的數據映射到只有客戶端依賴的對象。

耦合你也耦合你的圖層。控制器層應該僅取決於服務層，而服務層應該僅取決於DAO層。

交易所有交易都應該在服務層處理（因爲服務方法可能會調用多個DAO方法）。

業務邏輯 所有的業務邏輯應該在你的服務層。因此，你不應該直接調用DAO來繞過這樣的邏輯。

我知道，對於像findAll這樣的方法來說，它似乎沒有意義，但我認爲關於圖層耦合的觀點會失敗這個論點。

來源

2015-04-29 08:30:19 JamesB

+1。另一點可能是安全。如果使用方法級別的安全性並將DAO調用包裝在服務中，那麼您只需要一個位置來保護（服務），因爲通常只能從某個事務（即從服務層）調用DAO。這假設DAO本身不是事務性的（這也是你提到的一個好習慣）。 –

是的，如果某些開發人員直接從其他層（即服務層或其他任何體系結構）直接調用DAO層代碼，那麼這可能是一個痛苦：使用maven依賴關係創建4-5個不同的模塊爲您的項目，並提到在pom.xml依賴關係，以便不會從任何其他不正確的層進行調用。爲了使它更清楚： - 如果你只想從第4層訪問第3層，只需要在第3層添加一個依賴項，並且沒有其他模塊可以訪問第3層，他們就不能從它調用代碼。

你肯定會得到數百個這樣做的例子。

來源

2015-04-29 08:31:54

混合DAO和服務調用

回答

相關問題