我看 MVC 设计中 dao 层和 service 都说要加一个 dao.impl 而我在实际应用中感觉加一个 dao.impl 非常麻烦，比如我需要修改 dao.impl 还要修改 dao 这样不增加了负担吗？他的好处是干什么用的，一直没明白。
MVC
dao
service
dao.impl
ringa_lee
dao中存在是介面(interface) dao.impl中存在的是介面的具體實作(class)
至於好處，去查查介面的定義。
舉例
dao中有
public interface UserDAO { public List getUser(); }
dao.imple中
public class JdbcUserDao implements UserDAO{ @Override public List getUser() { //do sth. return null; } }
在往後的某一天，需要用hibernate來操作資料庫的時候。 只要寫一個 HibernateUserDao來實作UserDAO就行了。
介面定義的是規範。並不關心具體實現。 我的github上有一份自己對java各種關鍵字做的總結，其中關於介面在設計上的描述是：
介面作為系統與外界互動的窗口，介面體現是一種規範。對於介面的實作者而言，介面規定了實作者必須向外提供哪些服務(以方法的形式來提供)；對於介面呼叫者 而言，介面規定了呼叫者可以呼叫哪些服務，以及如何呼叫這些服務（就是如何來呼叫方法的）。當一個程式中使用介面時，介面是多個模組之間的耦合標準；當多 個應用程式之間使用時，介面時多個程式之間的通訊標準。 從某種程度來說，介面類型整個系統中的“總綱”，它制定了系統之間各個模組應該遵循的標準，因此一個系統中的介面不應該經常改變。一旦介面改變，對整個系統 甚至其他系統的影響將是輻射式的，導致系統中大部分類別需要重寫。
@zaz @reeco @finallygo 說的都是以介面為導向的優勢，這些內容不需要懷疑。 但根據個人的經驗，感覺這是一個可以酌情妥協的設計方案。筆者一直做的都是一些小項目，有時候也用到過一些設計模式，但是題主說的這種設計，感覺對小項目來說，弊大於利，代碼層數太多，多了許多沒有用處的介面程式碼，而且，介面在程式設計上是起不到應有的作用，就比如@zaz 所說，一個UserDao的介面可以有數個不同的實現，但是，項目小的情況下，這種情況用的還是比較少的。而且，題主既然能問出這種問題，那麼我想，在題主的專案中用到dao層介面的地方應該也是很少的。
面向介面程式設計是一種設計思想，個人感覺，所有的設計思想都應該是活的，不應該生硬的直接搬過來用。開發者首先應該理解這種思想，然後再看程式是否需要用到這種設計，沒有必要的話，即使是再優秀的設計，對程式來說，也是沒有多大意義的。
List<Integer> list = new ArrayList<Integer>(); List<Integer> list = new LinkedList<Integer>(); ........
java API 中存在大量這樣的設計,至於為什麼,建議樓主看看設計模式中的面向介面程式設計。好處說起來很空洞，只有上手了1，2個項目才能有所體會的。 有些經驗與心得必須經歷過才能得到。
一個是抽象,一個是具體 介面正常來說應該是一開始就設計好的,不能隨意的修改,如果你經常修改,首先需要考慮dao層是否考慮的足夠充分 而為什麼有介面層,是為了進行更好的隔離,最簡單的例子就是,如果你對service層需要進行單元測試了,而又不希望你對dao層進行實際的操作(可能是條件不允許) ,這時你很可能需要針對測試去mock一個dao出來,接口的優勢就體現出來了
分dao和service層是程式解耦需要，這麼做可以降低程式耦合度，可以在更換不同dao和不同service時，可以做到最低最小的修改程式碼。另外dao和impl的關係就是想規範和實現的關係，規範改了，實現當要改然，反之不一定。為了程式的解耦，這麼做還是可接受的。不然像spring這種框架會這麼火爆。
其實就是解耦，比如你的你有一個dao，dao.impl是一個MYSQL的實現，後來有需求要求改為Oracle實現，你只需要修改dao.impl為Oracle實現就好了，不需要修改dao和使用到dao的地方
簡單的說，為了方便用Strategy模式取代實作
上面說的很好了，以我自己的體會，在小專案中，真是弊大於利。專案比較複雜，多人合作，需求變動性比較大的話，還是很有用的，主要還是介面的隔離性，可以解耦模組之間的關聯。
dao和daoiml體現了兩個思想。 一是分層。我們為什麼要分層，分層解決了我們什麼問題？分層又有什麼優缺點？具體見我的部落格：http://www.inter12.org/archives/396 二是OO設計原則中的依賴倒置，抽象隔離。再具體點就是兩點： 1.高層模組不應該依賴底層模組，兩者應該都依賴抽象 2.抽像不應該依賴細節，細節應該依賴抽象 好處就是高內聚，低耦合，這兩個用爛的字！ ！
如果沒有更換資料庫的需求，其實去掉也沒事的
dao中存在是介面(interface)
dao.impl中存在的是介面的具體實作(class)
至於好處，去查查介面的定義。
更新。 。 。 。
舉例
dao中有
dao.imple中
在往後的某一天，需要用hibernate來操作資料庫的時候。
只要寫一個 HibernateUserDao來實作UserDAO就行了。
介面定義的是規範。並不關心具體實現。
我的github上有一份自己對java各種關鍵字做的總結，其中關於介面在設計上的描述是：
@zaz @reeco @finallygo 說的都是以介面為導向的優勢，這些內容不需要懷疑。
但根據個人的經驗，感覺這是一個可以酌情妥協的設計方案。筆者一直做的都是一些小項目，有時候也用到過一些設計模式，但是題主說的這種設計，感覺對小項目來說，弊大於利，代碼層數太多，多了許多沒有用處的介面程式碼，而且，介面在程式設計上是起不到應有的作用，就比如@zaz 所說，一個UserDao的介面可以有數個不同的實現，但是，項目小的情況下，這種情況用的還是比較少的。而且，題主既然能問出這種問題，那麼我想，在題主的專案中用到dao層介面的地方應該也是很少的。
面向介面程式設計是一種設計思想，個人感覺，所有的設計思想都應該是活的，不應該生硬的直接搬過來用。開發者首先應該理解這種思想，然後再看程式是否需要用到這種設計，沒有必要的話，即使是再優秀的設計，對程式來說，也是沒有多大意義的。
java API 中存在大量這樣的設計,至於為什麼,建議樓主看看設計模式中的面向介面程式設計。好處說起來很空洞，只有上手了1，2個項目才能有所體會的。 有些經驗與心得必須經歷過才能得到。
一個是抽象,一個是具體
介面正常來說應該是一開始就設計好的,不能隨意的修改,如果你經常修改,首先需要考慮dao層是否考慮的足夠充分
而為什麼有介面層,是為了進行更好的隔離,最簡單的例子就是,如果你對service層需要進行單元測試了,而又不希望你對dao層進行實際的操作(可能是條件不允許) ,這時你很可能需要針對測試去mock一個dao出來,接口的優勢就體現出來了
分dao和service層是程式解耦需要，這麼做可以降低程式耦合度，可以在更換不同dao和不同service時，可以做到最低最小的修改程式碼。另外dao和impl的關係就是想規範和實現的關係，規範改了，實現當要改然，反之不一定。為了程式的解耦，這麼做還是可接受的。不然像spring這種框架會這麼火爆。
其實就是解耦，比如你的你有一個dao，dao.impl是一個MYSQL的實現，後來有需求要求改為Oracle實現，你只需要修改dao.impl為Oracle實現就好了，不需要修改dao和使用到dao的地方
簡單的說，為了方便用Strategy模式取代實作
上面說的很好了，以我自己的體會，在小專案中，真是弊大於利。專案比較複雜，多人合作，需求變動性比較大的話，還是很有用的，主要還是介面的隔離性，可以解耦模組之間的關聯。
dao和daoiml體現了兩個思想。
一是分層。我們為什麼要分層，分層解決了我們什麼問題？分層又有什麼優缺點？具體見我的部落格：http://www.inter12.org/archives/396
二是OO設計原則中的依賴倒置，抽象隔離。再具體點就是兩點：
1.高層模組不應該依賴底層模組，兩者應該都依賴抽象
2.抽像不應該依賴細節，細節應該依賴抽象
好處就是高內聚，低耦合，這兩個用爛的字！ ！
如果沒有更換資料庫的需求，其實去掉也沒事的