搜尋

首頁  >  問答  >  主體

mvc - java 包 dao 和 dao.impl 问题

我看 MVC 设计中 dao 层和 service 都说要加一个 dao.impl 而我在实际应用中感觉加一个 dao.impl 非常麻烦,比如我需要修改 dao.impl 还要修改 dao 这样不增加了负担吗?他的好处是干什么用的,一直没明白。

ringa_leeringa_lee2807 天前1262

全部回覆(11)我來回復

  • 怪我咯

    怪我咯2017-04-17 13:03:02

    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各種關鍵字做的總結,其中關於介面在設計上的描述是:

    介面作為系統與外界互動的窗口,介面體現是一種規範。對於介面的實作者而言,介面規定了實作者必須向外提供哪些服務(以方法的形式來提供);對於介面呼叫者
    而言,介面規定了呼叫者可以呼叫哪些服務,以及如何呼叫這些服務(就是如何來呼叫方法的)。當一個程式中使用介面時,介面是多個模組之間的耦合標準;當多
    個應用程式之間使用時,介面時多個程式之間的通訊標準。
    從某種程度來說,介面類型整個系統中的“總綱”,它制定了系統之間各個模組應該遵循的標準,因此一個系統中的介面不應該經常改變。一旦介面改變,對整個系統
    甚至其他系統的影響將是輻射式的,導致系統中大部分類別需要重寫。

    回覆
    0
  • 迷茫

    迷茫2017-04-17 13:03:02

    @zaz @reeco @finallygo 說的都是以介面為導向的優勢,這些內容不需要懷疑。
    但根據個人的經驗,感覺這是一個可以酌情妥協的設計方案。筆者一直做的都是一些小項目,有時候也用到過一些設計模式,但是題主說的這種設計,感覺對小項目來說,弊大於利,代碼層數太多,多了許多沒有用處的介面程式碼,而且,介面在程式設計上是起不到應有的作用,就比如@zaz 所說,一個UserDao的介面可以有數個不同的實現,但是,項目小的情況下,這種情況用的還是比較少的。而且,題主既然能問出這種問題,那麼我想,在題主的專案中用到dao層介面的地方應該也是很少的。

    面向介面程式設計是一種設計思想,個人感覺,所有的設計思想都應該是活的,不應該生硬的直接搬過來用。開發者首先應該理解這種思想,然後再看程式是否需要用到這種設計,沒有必要的話,即使是再優秀的設計,對程式來說,也是沒有多大意義的。

    回覆
    0
  • 怪我咯

    怪我咯2017-04-17 13:03:02

    List<Integer> list = new ArrayList<Integer>();
    List<Integer> list = new LinkedList<Integer>();
    ........
    

    java API 中存在大量這樣的設計,至於為什麼,建議樓主看看設計模式中的面向介面程式設計。好處說起來很空洞,只有上手了1,2個項目才能有所體會的。 有些經驗與心得必須經歷過才能得到。

    回覆
    0
  • 大家讲道理

    大家讲道理2017-04-17 13:03:02

    一個是抽象,一個是具體
    介面正常來說應該是一開始就設計好的,不能隨意的修改,如果你經常修改,首先需要考慮dao層是否考慮的足夠充分
    而為什麼有介面層,是為了進行更好的隔離,最簡單的例子就是,如果你對service層需要進行單元測試了,而又不希望你對dao層進行實際的操作(可能是條件不允許) ,這時你很可能需要針對測試去mock一個dao出來,接口的優勢就體現出來了

    回覆
    0
  • 伊谢尔伦

    伊谢尔伦2017-04-17 13:03:02

    分dao和service層是程式解耦需要,這麼做可以降低程式耦合度,可以在更換不同dao和不同service時,可以做到最低最小的修改程式碼。另外dao和impl的關係就是想規範和實現的關係,規範改了,實現當要改然,反之不一定。為了程式的解耦,這麼做還是可接受的。不然像spring這種框架會這麼火爆。

    回覆
    0
  • 迷茫

    迷茫2017-04-17 13:03:02

    其實就是解耦,比如你的你有一個dao,dao.impl是一個MYSQL的實現,後來有需求要求改為Oracle實現,你只需要修改dao.impl為Oracle實現就好了,不需要修改dao和使用到dao的地方

    回覆
    0
  • ringa_lee

    ringa_lee2017-04-17 13:03:02

    簡單的說,為了方便用Strategy模式取代實作

    回覆
    0
  • 阿神

    阿神2017-04-17 13:03:02

    上面說的很好了,以我自己的體會,在小專案中,真是弊大於利。專案比較複雜,多人合作,需求變動性比較大的話,還是很有用的,主要還是介面的隔離性,可以解耦模組之間的關聯。

    回覆
    0
  • 大家讲道理

    大家讲道理2017-04-17 13:03:02

    dao和daoiml體現了兩個思想。
    一是分層。我們為什麼要分層,分層解決了我們什麼問題?分層又有什麼優缺點?具體見我的部落格:http://www.inter12.org/archives/396
    二是OO設計原則中的依賴倒置,抽象隔離。再具體點就是兩點:
    1.高層模組不應該依賴底層模組,兩者應該都依賴抽象
    2.抽像不應該依賴細節,細節應該依賴抽象
    好處就是高內聚,低耦合,這兩個用爛的字! !

    回覆
    0
  • 怪我咯

    怪我咯2017-04-17 13:03:02

    如果沒有更換資料庫的需求,其實去掉也沒事的

    回覆
    0
  • 取消回覆