一个应用或者说是系统，从一定程度上可以说是数据的流转。
一般的应用分层为：表现层，应用层，数据访问层。从最简单的spring应用来看，一般系统分成前端表现层，controller层，service层，dao层。
前端组织数据发送到后台，controller接受到数据，做数据的基本判断和转发，调用到service层；service层主要做业务的逻辑处理，调用dao层进行数据的增删改查；dao层是最基本的与数据库的交互。
一般应用系统直接用实体模型model作为表现层中的数据模型，这样看起来类少了很多，但是会有很多的问题。
1.如果实体模型发生变化，前端需要跟着改变
2.方法签名不明确，一般service中方法参数都变成了实体模型，不看底层代码，很难判断具体有哪些数据为空，哪些字段有值，导致方法意义不明确
一般建立数据传输模型DTO，用来做层与层时间的数据传递，DTO应当完全面向UI设计，没有行为属性。
一般来说，数据模型model是面向业务的，数据传输模型DTO是面向UI的。这样我们可以把表现层和数据模型解耦，层与层之间调用更加意义明确。
事物都有两面性，建立了DTO模型之后，会导致类大量增加，并且要进行DTO到model的映射。
在实际中，我们之前没有使用DTO层，导致我们遇到一个问题，用mybatis更新操作时，如果所有的更新都用同一个mapper方法，会有一定的问题。
例如：数据模型A，有五个字段A1~A5，接口1要更新A1~A4，接口2要更新A2~A4，根据DTO模型，接口A1只传递数据A1~A4，A5为空；接口2只传递数据A2~A5，A1为空。
同一个mapper方法中，我们使用mybatis的if语句判断是否需要更新这个字段，if(param！=null && param ！= “”) 更新这个字段为新值，会导致本身接口要清空这个值无法成功。
如果改成if(param！=null)更新这个字段，会导致，如果接口1中A5为空传而不是null，会导致错误的更新了这个值。
使用了DTO层之后，从根本上杜绝了误更新的情况，因为如果不更新这个字段，前端包括层与层之间的传递这个字段一定会是null。
