我对DAO的理解

Context

上午review一个新项目的代码，这个项目预估今年用户规模在500万以上。程序架构我已经搭建完成了，主要就是review一个同事写的业务代码。 我对他使用DAO的方式有很大的疑虑，虽然用了很长的时间讨论，但我无法说服他改变。 如鲠在喉，于是动笔写出我的意见，与大家交流。欢迎站在我同事的角度来说服我或再多给我一些能说服我同事的理由。

先描述一下同事写的代码，他把DAO当成一个工具类来用，没写实体类，而是讨巧的用Map做容器，用列名做key来存储实体，然后写了一个通用的方法支持增删改查。

我的理解

首先DAO是一种设计模式，用来分离低级别的数据访问逻辑与高级别的业务逻辑； 在实现上，数据访问对象（Data Access Object）是一个对象，它为某类数据库或持久存储系统提供一个抽象接口。应用程序对数据的操作都映射到持久层，DAO提供具体的数据操作而不暴露数据库的详细信息，从而实现底层数据操作逻辑与业务逻辑的分割。 一个典型的DAO实现有以下组件：

1. 一个获取DAO对象的工厂类
2. 一个定义DAO如何操作数据的接口
3. 一个实现了DAO接口的具体类
4. 数据传输对象(DTO)或称域对象(Domain)/实体类（Entity）

把DAO层变成一个工具类让我们失去了什么？

1. Map替代DTO的副作用：
看不到清晰的业务域对象，不知道哪些域对象具有可用的持久存储；无法利用IDE的自动完成特性；这无疑会降低程序的可读性；
2. 失去了类型安全性：
损失了编译时发现某些问题的可能性，可能降低程序的可靠性；
3. 混淆了数据逻辑与业务逻辑：
业务逻辑在获取数据对象时还需要写出SQL，完全没有隔离数据访问逻辑和业务逻辑，缺乏隔离的代码重构也会遇到更大的阻力

Reference

• http://en.wikipedia.org/wiki/Data_access_object