我在这里问的原因可能是，如果这个功能是“通过设计”，有人可以澄清为什么它是这样的，也可能是一种方式，以不同的方式实现所需的功能，我想象将是90百分之百的民众希望这个工作？

实质上，我的想法在于UpdateModel中绑定进程的行为。

假设您希望通过简单的保存操作方法更新表单，表单上的数据字段将反映数据库中的模型，最初要保存请求，我们可能会从DB获取现有模型，然后更新相关的已更改的字段通过FormCollection发送，然后由UpdateModel更新为现有模型。这个功能，但是这个DB填充对象的任何现有属性似乎都是“reset”;我的意思是，被设置为null或初始化默认，就好像它是一个全新的对象，除了显然那些与FormCollection匹配的对象。

这是一个问题，因为对象上存在的但不一定存在于表单上的任何现有属性(如任何子集合或对象，日期或任何非UI面向字段)都为空，从而使您拥有一个半填充，更多或更少的不可用的对象，由于所有丢失的数据，包括可能的一堆ID现在设置为0，无法保存到DB。

我相信这是不理想的行为，UpdateModel应该只更新在它在FormCollection中找到属性匹配的属性。这将意味着您现有的所有属性将保持不变，但您的更新将被设置。然而，从迄今为止推断出来的情况显然不是这样 – 它似乎实例化了一个全新的对象副本从表单中更新属性，然后返回新对象。

最后，为了说明这是多少负担，唯一的方法是保存半复杂形式并保留所有现有的对象数据是手动结束每个属性与相应的表单属性绝对仅保证表单中存在的属性正在更新。

我猜，

>那些同意这是设计的人，我的方式是结婚最好的方式吗？
>或者，你怎么处理这个？

谢谢你，请随便提供你的想法。

这是另一个遇到这个问题的人的例子：
Calling UpdateModel with a collection of complex data types reset all non-bound values?