需要單獨的接口和用於DAO的impl

我們有一個典型的n層java應用程序，並且我注意到我們的數據訪問層具有類型爲FooDAO和FooDAOImpl的DAO。我期待證明這兩者的必要性，這是我的分析。需要單獨的接口和用於DAO的impl

如果您對同一接口有多個實現，抽象是有幫助的。但鑑於我們已經選擇了用於DAOImpl的框架（比如iBATIS），它真的需要嗎？
幫助代理通過春天。從我所收集的內容來看，具有接口的類可以很容易地進行代理（使用JdkProxy路由），而不是無接口的類（其中選擇了cglib路由），並且有一個類需要代理的子類。子類化的問題在於，代理的類是最終的，或者沒有默認的構造函數 - 兩者在數據訪問層上都不太可能。性能曾經是一個因素，但從我所聽到的，它不再是一個令人擔憂的原因。
幫助嘲笑。具有接口的類更適合被模擬框架嘲笑。我只聽過這個，但在實踐中沒有看到它 - 所以不能真正指望它，但也許是因爲上面＃2中提到的相同因素。

有了這些觀點，我不覺得真的需要一個單獨的FooDAO和FooDAOImpl，其中一個簡單的FooDAO應該足夠了。隨時糾正我提到的任何問題。

在此先感謝！

2012-07-04 Kilokahn

除非我錯了，你不要在這裏問一個問題嗎？使用接口與注入接口的好處已經在你的'問題'中陳述了...... – steelshark

是的，你已經闡述了使用接口和實現DAO的三個很好的理由。我會向你提出相反的結論，即需要有一個接口！ –

@ user935439問題出在每個要點上。儘管我們原則上同意接口的好處，但我想收集關於減少我必須編寫和維護的類文件的意見的觀點，因爲在此類用例中接口的好處並不完全明顯。你有沒有用例子知道，當你有涉及接口的時候，嘲笑更容易？謝謝！ – Kilokahn

我嘗試＃3與Mockito和它能夠模擬POJO的沒有接口就好了。由於針對＃1和＃2提出的論點，我傾向於暫時不要單獨使用DAO和DAOImpl。隨意添加其他比較點。

2012-07-10 16:09:05 Kilokahn

我看到了第四個原因：

取決於例如對球隊，對軟件的預期壽命或變化對未來預期的量，它支付儘可能隱藏即使只有一個實現。

2012-07-04 08:25:59

我會說有一個FooDAO接口與單個實現FooDAOImpl通常是反模式。更簡單的解決方案（沒有單獨的DAO接口）是非常可取的，除非你有一個堅實的原因，否則 - 在這裏似乎不是這種情況。

就我個人而言，我會走得更遠，並說，擁有DAO並不是最好的選擇。我更喜歡在ORM API（如Hibernate或JPA）上實現一個持久性外觀類。不過，也許iBATIS對此太低級了。

2012-07-10 19:08:47

回答