在建立一个实体类的时候，究竟是用Model还是用Entity？比如MVC中，Model存了数据实体，但是他被称为Model，而在EF中，Entity也是存放数据实体，却被称作Entity，这两者有何区别？那究竟什么时候应该用Model什么时候应该用Entity呢？
赵劼：
一般这种称谓都是根据上下文来的，例如Model是因为有MVC，或MVVM的场景下所以叫做Model，这里的Model就是一种职责。Entity则更接近是一种表达业务概念的实体，例如一个User，一个Order等等，而这样的实体在MVC中起到Model的职责。EF的作用是帮助你存取Entity的，而不关心你把这个Entity用作MVC里的Model还是Observer模式中的Subject对象。
当然以上都是我常用的理解方式，不同的项目内部完全可以有不同的理解方式，只要项目内部统一，不会引起混淆即可。命名一直是件很难的事情，实际中绝大部分项目都是要权衡的，也都是有各种不完美的地方的。例如，.NET类库中各种ObservableCollection，ReadOnlyCollection，按照“规范”都应该叫做ObservableList，ReadOnlyList，而Collection这是个更宽泛的概念。
我们可以花一部分精力去考虑这方面问题，但也不用纠结太多，头大且对项目也没太大帮助。
作者：赵劼
链接：http://www.zhihu.com/question/25256772/answer/30290376
来源：知乎
著作权归作者所有，转载请联系作者获得授权。
MVC是模式，EF是ORM，角色不同。MVC里面的Model是C发给V的。这些Model应该被高度优化，仅仅被对应的View用来显示，额外的数据应该被Model层砍掉以节省磁盘访问、内存占用或者数据库带宽。通常情况下，View的数量都会比你数据库的Entity要多，比如用户要求的各种各样的报表，所以对应的Model也应该比数据访问层的Entity多。
用编写资源管理器界面打个比方。在不同的显示模式下。这里的Model可以是WIN32_FIND_DATA这样的常用文件属性。也可以是常用文件属性加上IShellItemImageFactory返回的缩略图。
假设你的View和你的EF的实体类完全一一对应，可以不编写额外的Model。但是随着需求的增多，很难一直使用EF的实体类来做Model。
作者：蒋晟
链接：http://www.zhihu.com/question/25256772/answer/30301743
来源：知乎
著作权归作者所有，转载请联系作者获得授权。
