ViewModel与Entity的区别及API交互、POST操作对象选型疑问

问题1：API返回数据的接收方式 #

不要先映射到Entity再转ViewModel，直接用ViewModel接收API返回的数据

原因很明确：Entity是和数据库强绑定的实体，通常包含主键、创建时间、版本号等UI完全不需要的字段，甚至可能带有关联数据库的导航属性。如果API返回的是经过处理的、仅面向UI展示的数据，直接用ViewModel接收更高效——既减少了不必要的映射步骤，也避免把数据库层的细节暴露到UI层。

如果是你自己开发的API，正确流程应该是：API从数据库获取Entity后，在API层用AutoMapper把Entity转换成ViewModel（或DTO，本质和你说的ViewModel作用一致）再返回，移动端直接接收这个ViewModel渲染界面即可。

问题2：POST请求的请求体选择 #

优先使用专门的请求模型（比如叫RequestModel），而非ViewModel或Entity

• 为什么不用Entity？Entity是数据库层的对象，包含很多数据库相关的冗余字段（比如自增ID），POST提交时根本不需要这些字段，强行用Entity会导致请求体冗余，甚至可能因为字段不匹配引发错误；另外，UI层直接依赖数据库实体，会让代码耦合度变高，后续数据库结构变更时，UI层也要跟着改，非常不灵活。
• 为什么不直接复用ViewModel？如果你的ViewModel刚好和POST需要提交的字段完全一致（比如某个页面的ViewModel只包含需要提交的内容），临时复用没问题，但大多数情况下，ViewModel会包含一些用于展示的字段（比如显示用的昵称、状态文本），这些字段不需要提交给API，强行复用会导致请求体携带无用数据。

举个你提到的「提交用户名密码」的例子：应该单独创建一个LoginRequest模型，只包含Username和Password两个字段，UI把输入框的内容填入这个模型后再发起POST请求。这样请求体干净，也能在模型里做输入校验（比如密码长度、格式规则），职责更清晰。

总结分层流程（适配你的API+移动端项目） #

1. 移动端UI层：用ViewModel存储展示数据，用RequestModel封装提交的请求数据
2. API层：接收RequestModel，转换为Entity执行数据库操作；查询数据库得到Entity后，转换为ViewModel返回给移动端
3. 用AutoMapper处理Entity和ViewModel/RequestModel之间的映射，减少手动编写转换代码的工作量

内容的提问来源于stack exchange，提问作者Kemal