對《關於Dao層職責的思考》一文的修正

之前寫過一篇關於DAO職責的文章，近來發現不對，我錯了，在反覆閱讀了《阿里巴巴java開發手冊》後，我重構了本身對這部分知識的認知。內容以下：

關於返回值

• 從dao返回的數據，要麼是基本數據類型，要麼是DO實體。

• 從service返回的數據，要麼是基本數據類型，要麼是DTO實體。

DAO如何工做

每一個DAO應該有一個主表，圍繞這個主表產生DO，同時儘可能避免聯表。

《高性能Mysql》中有這樣一段話：

不管如何排序都是一個成本很高的操做，因此從性能角度考慮，應儘量避免排序或者儘量避免對大量數據進行排序。

若是 ORDER BY 子句中的全部列來都來自關聯的第一個表，那麼mysql在關聯處理第一個表的時候就進行文件排序。除此以外的全部狀況，mysql都會先將關聯的結果放到一個臨時表中，而後在全部的關聯都結束後，再進行文件排序。

僅供參考：我認爲思考某段sql應該進入哪一個DAO的時候，你須要思考這段SQL的主表是誰，而上面給出的信息，是思考這個問題的一個很不錯的提示。

一些小細節

• mapper的查詢條件若是使用枚舉來映射數據庫表中的字段，不該該在枚舉中添加數據庫沒有的數值，好比用某個數來表示「所有」這個概念（但其實數據庫中並無一個狀態值和它對應）。若是你這麼作，你會發現當你須要使用集合來配合IN查詢的時候，多出來的數值會成爲你的麻煩。

• 下層爲上層服務，以目標爲導向。上層（業務邏輯層）須要什麼，下層（數據訪問層）就提供什麼。而不是下層（數據訪問層）有什麼，上層（業務邏輯層）使用什麼。

• dao層不提供計算屬性，只提供真實存在的屬性。（雖然上層看不出來dao提供的屬性是真實存在的仍是計算出來的，但遵照這一點可讓你的sql與業務邏輯有效隔離。）

• dao層有兩個部分，一是承載實際代碼的mapper.xml，一是提供接口的mapper.java。mapper.java要提供清晰明確的參數列表和返回值，禁止使用Map作參數和返回值。

• 任何NEP問題，都由數據使用者來保證。（你要假設任何基本數據類型外的數據都有可能爲NULL，並對出現NULL的狀況作出處理）

• 對數據庫的操做要聚合到特定的接口上，數據查詢則不須要。這樣有助於控制數據的修改。