0815model、entity、实体以及和其他层的关系

1.model译为模型；entity译为实体

2.model通常会包含方法，entity可以是独立的数据类型，如map，list等等

3.entity也包含方法，但这些方法并不是自己设计的，如map的自带方法，redis数据库自带这一orm设计者所设计的方法

4.dao层既可以调用数据库实体，如mysql，redis；也可以调用这些已存在的实体，可被调用的目标满足如上“3”所描述特性

5.模型往往是指代类本身，实体往往只带一个模型实例化后之所得

6.模型往往与数据库内数据的映射高度吻合，是数据库在项目中的第一次抽象

7.由这第一次抽象所得的结果经过二次加工，可以说是模型的实体，也可以是实体

8.实体可以作为数据源，模型绝对不会是最底层数据源，比如当前项目中，数据源来自套接字，通过process层提取成model.curUser

9.dao层或者service层需要实现对数据源的封装，为最在层只暴露所需要的接口。

10.非model层和entity层都可以创建model或entity的实体，但是model层和entity层不能创建其他层的实体

11.并不是只有在dao层里可以创建model或entity实体，其他层根据需求也可以，尤其是service层

重点：entity层与model层的区别或许很类似process层与dao层，区别来自于更加底层的数据源类型，model层往往来自于数据库，以及对其的再此加工，如User和[]User。entity则来自于更加独立的业务上的储存数据的需求，如金鱼师傅把从232设备中返回的数据翻译后直接扔进了一个大数组里mylist[][][][][][][][][]，流程相当于232conn->process->entity->(dao)->service->view

有个问题，这样的实体属于缓存吗？

其实没必要在概念上做过多纠缠，只是分层目前被大家认可了，所以都这样说，其实分层的目的只是为了让程序在设计的过程中就做好基础，在分工、实现和扩展上都有很好的表现，所以分层得到很大应用，但是具体每层叫什么，干什么用，我觉得没必要纠缠只要和多数人能达成共识以达到沟通的目的就可以了，学习别人的代码，主要是看人家在扩展、可维护这类内容上的优点，有哪些是可以借鉴的就可以了，具体的东西每个项目，每个领域的东西也都不太一样的，主要根据实际问题能有很好的解决方法就行了