对《关于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的状况作出处理）

• 对数据库的操做要聚合到特定的接口上，数据查询则不须要。这样有助于控制数据的修改。