Johnny's Collections

@isnumeric
PO應(yīng)該是我系列博文所說(shuō)的DTO，它是實(shí)體的信息封裝對(duì)象，本質(zhì)上與“實(shí)體的查詢信息封裝對(duì)象”是不同的，因此最好提供一個(gè)Criteria來(lái)封裝查詢屬性。

HQL絕對(duì)不能封裝在Service中，因?yàn)镠QL涉及數(shù)據(jù)訪問(wèn)邏輯，應(yīng)該封裝在數(shù)據(jù)訪問(wèn)層中，業(yè)務(wù)層可以傳入生成HQL的相關(guān)數(shù)據(jù)，由DAO把這些數(shù)據(jù)轉(zhuǎn)換為HQL，但Service絕對(duì)不要傳入任何與數(shù)據(jù)訪問(wèn)實(shí)現(xiàn)細(xì)節(jié)有關(guān)的數(shù)據(jù)，否則Service就被耦合了。

@DDD
對(duì)，但頁(yè)面查詢用的VO，與表示某個(gè)實(shí)體的VO不是同一樣?xùn)|西，如果按我的博文中合并VO與DTO的說(shuō)法，舉個(gè)例子，User，對(duì)應(yīng)的信息DTO應(yīng)該是UserInfo，而對(duì)應(yīng)的查詢User的DTO應(yīng)該是另外一個(gè)，通常我用UserSearchCriteria來(lái)代替，為什么要把UserInfo和UserSearchCriteria區(qū)分開(kāi)來(lái)？你可能認(rèn)為，UserInfo中大部分屬性，都是可以用于查詢的，所以沒(méi)必要弄多一個(gè)UserSearchCriteria，但事實(shí)上，它們本質(zhì)上是兩樣?xùn)|西來(lái)的，比如，UserInfo有一個(gè)birthday的屬性，但對(duì)于查詢來(lái)說(shuō)，系統(tǒng)可能要求查詢某個(gè)時(shí)間段內(nèi)出生的User，這個(gè)時(shí)候，UserSearchCirteria就要定義兩個(gè)屬性birthdayFrom，birthdayTo了，所以可以看出，兩者只是“表面上相似”，本質(zhì)上是兩樣?xùn)|西，為了設(shè)計(jì)上的靈活性和擴(kuò)展性，即使當(dāng)前情況下兩者的屬性一致，也需要分別進(jìn)行設(shè)計(jì)。

@Aidan
聯(lián)系方式已經(jīng)發(fā)到你的郵箱，請(qǐng)查收

@Aidan
呵呵，謝謝你的持續(xù)關(guān)注，你這個(gè)問(wèn)題同樣很好，我也曾經(jīng)被這個(gè)問(wèn)題困擾，你所說(shuō)的從構(gòu)造函數(shù)傳入，從技術(shù)角度來(lái)講，是一種可行的辦法，但我不建議這樣做，原因是：
1）DO（即你所說(shuō)的BO）從業(yè)務(wù)上來(lái)講，不應(yīng)該與DAO有關(guān)聯(lián)，因?yàn)镈AO對(duì)于業(yè)務(wù)來(lái)說(shuō)是沒(méi)有意義的，它屬于應(yīng)用方面的東西。DO構(gòu)造函數(shù)只能包括用于構(gòu)造它的所必須的元素（我后面的博文會(huì)提及）。
2）這樣做會(huì)讓DO與你的具體實(shí)現(xiàn)耦合，試想，如果某天有某種更好的方法讓你動(dòng)態(tài)注入DAO，意味著你不再需要通過(guò)構(gòu)造函數(shù)傳入DAO了，那么你是繼續(xù)保留這個(gè)參數(shù)，還是修改構(gòu)造函數(shù)，從而讓所有調(diào)用該構(gòu)造函數(shù)的客戶程序受到影響呢？

事實(shí)上，可行的做法有兩種：
1）利用Spring提供的“動(dòng)態(tài)注入”方式，這種方式的原理是，通過(guò)一個(gè)Annotation，告訴Spring容器，這個(gè)DO是需要注入對(duì)象的，即需要受到SpringIoC容器管理，那么Spring就會(huì)利用“編譯時(shí)織入”或“啟動(dòng)時(shí)織入”的技術(shù)來(lái)為DO的Class類織入注入相關(guān)對(duì)象的代碼，這種技術(shù)依賴于AspectJ，前者更加需要在編譯環(huán)境加入AspectJ的增量編譯器，這種方案是相對(duì)麻煩的，而且我曾經(jīng)在OSGi中應(yīng)用，會(huì)出現(xiàn)一些不可預(yù)知的問(wèn)題導(dǎo)致無(wú)法注入。

2）在你的應(yīng)用（通常是Web應(yīng)用）加載SpringContext的時(shí)候，設(shè)計(jì)一個(gè)用于保持SpringContext的ContextHolder，利用某種機(jī)制（例如Spring提供的Servlet）來(lái)在加載SpringContext的時(shí)候，把SpringContext的引用保留在該ContextHolder中，然后在你的DO里面，就可以在實(shí)現(xiàn)代碼里面通過(guò)ContextHolder提供的靜態(tài)方法，獲取到你所需要的Bean了。

@Aidan
很好的問(wèn)題，我逐個(gè)回答：
1.我所說(shuō)的不需要password，是值在DTO層面，同一個(gè)UserInfo（我在一篇博文中建議以***Info命名DTO，意為***信息），其實(shí)對(duì)于不同的場(chǎng)景，本質(zhì)上是不同的，例如，我有個(gè)注冊(cè)用戶的方法，需要傳入U(xiǎn)serInfo，那么逐個(gè)DTO必須擁有一些用戶認(rèn)證或隱私信息的屬性，但對(duì)于查詢用戶的方法，它返回的也是一個(gè)UserInfo，但這個(gè)UserInfo，從需求來(lái)說(shuō)，它不應(yīng)該包含密碼和隱私信息，那么這兩個(gè)雖然都是UserInfo，但理論上應(yīng)該定義為兩個(gè)獨(dú)立的DTO，但實(shí)際上，這樣做帶來(lái)的負(fù)面影響會(huì)更大，因?yàn)槲以谝粋€(gè)系統(tǒng)中可能要為一個(gè)實(shí)體定義太多的DTO，所以我建議定義一個(gè)包羅萬(wàn)有的DTO，但在返回?cái)?shù)據(jù)時(shí)，如果有些數(shù)據(jù)不應(yīng)該返回，就把屬性設(shè)置為null即可，當(dāng)然SOA中的SDO有另外的做法，這里不詳說(shuō)，本人也不甚精通。

2.對(duì)于VO，DTO，DO，PO的命名，我個(gè)人的建議（純屬個(gè)人意見(jiàn)），還是不要太過(guò)技術(shù)化，VO可以叫***View，代表一個(gè)”視圖“，DTO用***Info，代表”***的信息“，DO由于是就是業(yè)務(wù)實(shí)體本身，所以直接給它一個(gè)釋意名稱，如User、Customer……，至于PO，正如我所說(shuō)，現(xiàn)在的ORM框架已經(jīng)可以把這個(gè)東西在實(shí)現(xiàn)層面通過(guò)配置文件（xml）或annonation隱藏起來(lái)，所以在實(shí)現(xiàn)層面基本不需要存在，如果確實(shí)需要的話，我覺(jué)得”持久化“本身就是計(jì)算機(jī)世界的一個(gè)非業(yè)務(wù)領(lǐng)域，這里用技術(shù)化命名完全沒(méi)有問(wèn)題，因?yàn)樗_實(shí)是”技術(shù)化產(chǎn)物“，在業(yè)務(wù)領(lǐng)域沒(méi)有這個(gè)概念。這相信也同樣回答了你在另外一篇博文提出的問(wèn)題。

希望我的回答能讓你滿意。

@瀟湘振宇

支持原創(chuàng)

@菠蘿大象
Jdon框架采用DDD了么？沒(méi)有關(guān)注，不過(guò)個(gè)人覺(jué)得不解，DDD主要是針對(duì)企業(yè)應(yīng)用的，一個(gè)純技術(shù)框架，為什么要使用DDD。

謝謝樓主，很不錯(cuò)，希望多一些這類文章。

@spell007
您好，這個(gè)問(wèn)題問(wèn)得非常好，我之前在應(yīng)用DDD做一個(gè)項(xiàng)目的時(shí)候，就跟項(xiàng)目成員做過(guò)討論，我們發(fā)現(xiàn)，DO和Repository（即DAO，我習(xí)慣用非技術(shù)化命名來(lái)讓思維集中與業(yè)務(wù)而不是技術(shù)）兩者是雙向依賴的。原因是：
1）Repository必須依賴DO，因?yàn)樗繢O的數(shù)據(jù)結(jié)構(gòu)，這無(wú)可厚非。
2）為什么DO需要依賴于Repository呢？從實(shí)現(xiàn)角度來(lái)說(shuō)，我的賬戶轉(zhuǎn)賬業(yè)務(wù)就可以看出這種依賴的存在，另外有些場(chǎng)景，比如有些領(lǐng)域業(yè)務(wù)邏輯需要查詢一些數(shù)據(jù)，例如一個(gè)Order最多允許10個(gè)OrderItem，那么在order.addOrderItem的方法里面，就需要判斷當(dāng)前Order有多少個(gè)OrderItem，這就需要查詢（為了性能不全部加在OrderItem），從設(shè)計(jì)角度來(lái)看，我們想想，在計(jì)算機(jī)世界，由于DO在大部分情況下是必須持久化的，所以DO從功能上本身就對(duì)其Repository存在依賴關(guān)系，當(dāng)然，我們可以只依賴于接口，所以，基于 種種原因，我們不得不讓DO與Repository形成雙向依賴關(guān)系。

這個(gè)問(wèn)題值得詳細(xì)討論，我會(huì)考慮在后面的系列博文增加一篇專門(mén)針對(duì)這個(gè)問(wèn)題進(jìn)行分析討論，非常感謝你提出這樣好的問(wèn)題。

從設(shè)計(jì)的角度來(lái)看，通過(guò)了解一些底層機(jī)制，繞過(guò)OSGi的類加載策略來(lái)直接訪問(wèn)不對(duì)外公開(kāi)的類，不見(jiàn)得是一件好的事情，作為技術(shù)研究，了解這些底層機(jī)制有助于更熟悉一個(gè)框架，以更靈活的運(yùn)用它，但作為軟件開(kāi)發(fā)，這些做法可能會(huì)導(dǎo)致很多隱患和風(fēng)險(xiǎn)，個(gè)人認(rèn)為不值得推崇。

@何楊
工具有很多，我用的是Enterprise Architecture試用版，還可以用Jude等。

期待你的下一篇博文，特別是關(guān)于OSGi，緩存技術(shù)的博文

@onkyo
明白你的意思，謝謝你的意見(jiàn)，我往后會(huì)發(fā)表一些針對(duì)如何使用面向?qū)ο笏季S進(jìn)行設(shè)計(jì)，及其真正的好處的博文，當(dāng)中就會(huì)詳細(xì)的說(shuō)明使用面向?qū)ο笏季S在某些場(chǎng)景中的好處。

@BearRui(AK-47)
我是這樣想的，做開(kāi)發(fā)人員，基礎(chǔ)英語(yǔ)知識(shí)是必備的工具，很多技術(shù)文檔、規(guī)范、API都是英文的，即使有翻譯，也是讀英語(yǔ)的比較好，因此在我參與過(guò)的項(xiàng)目中，包括我曾經(jīng)工作過(guò)的公司，都是嚴(yán)禁使用拼音的。

@wpskl
前臺(tái)驗(yàn)證主要看需求和用戶體驗(yàn)，如果希望用戶填寫(xiě)信息時(shí)出現(xiàn)錯(cuò)誤馬上得到提醒，就需要做前臺(tái)校驗(yàn)，不過(guò)現(xiàn)在的軟件強(qiáng)調(diào)以用戶為中心（UCD）所以你的做法我是贊同的。

@onkyo
呵呵，回復(fù)一下這為同學(xué)的兩個(gè)評(píng)論，首先，你說(shuō)得對(duì)，static就不是面向?qū)ο螅兠嫦驅(qū)ο笫菦](méi)有static函數(shù)的，但我要解釋兩點(diǎn)，上面的代碼純屬演示如何改變一種思維方式，我并沒(méi)有過(guò)于斟酌于代碼的細(xì)節(jié)，如果要純面向?qū)ο蟮脑挘铱梢园裺tatic聲明為對(duì)象方法，然后讓這個(gè)類變成Singleton；其次，如果所有東西都要考慮繼承的話，就是過(guò)度設(shè)計(jì)對(duì)了，正如我在本博文的最后的特別說(shuō)明，設(shè)計(jì)是要針對(duì)需求的，假如我這個(gè)流程相當(dāng)穩(wěn)定，不存在多態(tài)的情況，那么我就（至少在目前）不需要過(guò)度的把它設(shè)計(jì)為接口，然后再提供實(shí)現(xiàn)類，再通過(guò)依賴注入，而關(guān)于你提到的private方法不能繼承和重用，這也是一個(gè)好問(wèn)題，假如根據(jù)實(shí)際情況，我不希望我的類或方法被繼承或重寫(xiě)，我就需要聲明其為final/private了，君不見(jiàn)JDK的很多類都是final的嗎？這同樣也回答了你第二個(gè)評(píng)論的問(wèn)題，沒(méi)需要多態(tài)，或沒(méi)需求切換實(shí)現(xiàn)，就沒(méi)必要接口。

總之，謝謝你的發(fā)言，我只能強(qiáng)調(diào)，上面的代碼純屬表達(dá)一種思維方式，況且，不考慮現(xiàn)實(shí)環(huán)境和實(shí)際需求，孤立的去討論一個(gè)類是否有接口，一個(gè)方法是否需求繼承，一個(gè)靜態(tài)方法是否必須設(shè)計(jì)為對(duì)象方法，都是沒(méi)有實(shí)際意義的，搞不好就是一種“過(guò)度設(shè)計(jì)”。

@問(wèn)樓上的人
我非常同意你的看法，設(shè)計(jì)是需求權(quán)衡的，設(shè)計(jì)是一種選擇，我寫(xiě)這篇博文是發(fā)現(xiàn)很多開(kāi)發(fā)人員沒(méi)有這種思想，并不是一刀切的要求都必須按設(shè)計(jì)方式生搬硬套。謝謝你的意見(jiàn)。