实体与模型的浅析
在日常开发过程中经常看到Entity，Model，DataModel，它们之间到底有什么异同？下面是我个人的一些理解。
一.Entity，Model，它们是什么？
维基百科描述:
实体（entity）是有可区别性且独立存在的某种事物，但它不需要是物质上的存在。尤其是抽象和法律拟制也通常被视为实体。
可见，实体就是软件系统中的研究对象。
比如:学生信息管理系统中，学生这一概念就是一个实体，它是我们软件系统的主要研究对象
数据模型(模型)：
在软件工程中，数据模型是定义数据如何输入与输出的一种模型。其主要作用是为信息系统提供数据的定义和格式。数据模型是数据库系统的核心和基础，现有的数据库系统(此处所指数据库为关系数据库，非关系数据库常见的是键值对形式存储数据)都是基于某种数据模型而建立起来的。
可见数据模型这个概念更多出现在数据库系统中。它是为了把研究对象进行抽象，目的是要与数据库系统中的数据模型进行关系映射。
从实体概念可以得知，实体正是数据库系统的研究对象，所以，建模过程即为为实体进行抽象和定义，用一个数据模型对实体进行描述，此数据模型则为数据库系统提供数据支持。
把这些概念引入到计算机系统之后，在不同的业务层有着不同的体现。
二.计算机系统中的数据模型
对于数据访问(传输)层的数据模型，更多是用于定义数据交换的文档结构，即对数据交换文档进行抽象和定义。某一个模型对应某一份数据交换文档，JAVA程序设计中最常见的是JavaBean，.NET程序设计中最常见的是xxxModel，它们的作用都是相同的，即把数据交换文档使用对应的程序设计语进行定义，使得整个数据文档可以在本系统中方便的使用。需要注意的是，xxxBean和xxxModel的存在侧重于抽象建模，故常见的xxxBean和xxxModel中很少出现对数据的操作,所以我们常见的xxxBean定义中更多的是看到一些数据成员的定义，很少看到方法定义。
对于业务逻辑层的数据模型，更多是用于对系统操作对象进行抽象和封装。对于此层的数据模型而言最常见的是我们在传统软件开发过程中，通过UML建模得到的类定义。我们把系统业务进行了抽象，以类的形式对其进行描述，使得整个系统结构化，模块化，业务针对性强，并且在开发过程中更加易于修改和维护。通过各个类所生成的对象之间的相互协同工作，即可完成相关的业务需求。所以此层中的数据模型不但有类型（数据）的定义，更多的是操作（方法）的定义。因为模型内或者模型之间需要有所通讯（互操作）。这就是业务逻辑层的数据模型，它是系统详细设计的产物。
三.关于命名
Entity , Model , DataModel在开发过程中经常看到这三个命名，其实他们都是同一个概念，即数据模型的定义,是对实体抽象描述的产物。JAVA程序设计中数据访问层的数据模型一般以Bean结尾，表示它是一个JavaBean，而.NET中更多的是使用Model作为后缀，也有人以Entity作为后缀，这也就解释了为什么任何一个项目中都免不了看到这三个单词。数据访问层的数据模型对数据访问权限没有要求，甚至可以说，必须对外开放访问，所以常见的数据成员的数据访问修饰符都是public ；业务逻辑层更多是以实体本身命名，比如:Student，Blog等，它要求具有较强的封装性，不但封装变化，更要封装操作，所以对于Client而言某些数据是无法访问的。
四.总结
实体是设计时存在的概念，不应该出现在计算机系统的具体定义中，而数据模型则是计算机系统中的操作对象的抽象，他们本为一个概念 – 系统研究对象的抽象，只所处环境不同导致所有差异。