在建立一个实体类的时候,究竟是用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
来源:知乎
著作权归作者所有,转载请联系作者获得授权。
---------------分---割-----线-----------------------
Entity是专用于EF的对数据库表的操作,而Model这是为页面提供数据和数据校验的,所以两者可以并存
---------------分---割-----线-----------------------
Entity接近原始数据,Model接近业务对象~
---------------分---割-----线-----------------------
蒋晟
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
来源:知乎
著作权归作者所有,转载请联系作者获得授权。