此处描述的行为现在似乎是 ASP.NET MVC 2 的默认行为（至少对于预览版 1）。
当对这样的查询字符串进行建模时：
?Foo=&Bar=cat
发生以下绑定（假设您绑定到具有 'Foo' 和 'Bar' 字符串属性的模型）
ASP.NET MVC 1
model.Foo = "";
model.Bar = "cat":
ASP.NET MVC 2（预览 1 到 RC）
model.Foo = null;
model.Bar = "cat":
想给任何正在玩 V2 的人提个醒，因为“ gu-notes ”中没有提到这一点。也很好奇是否有知情人士可以评论这是否将是最终实现或可配置功能？无论哪种方式我都很好，但只是希望他们不要切换回旧方式！可配置会更好。
编辑：从这一点学到的教训是，无论您开发的版本是什么，都不要编写代码 Foo.Length == 0 来测试空字符串或 Foo.Length > 3 来检查最小长度。使用 string.IsNullOrEmpty(Foo) 和/或首先检查 null。
更新：这个问题引发了我的好奇心，他们为什么会做出这种改变。我认为我在研究禁用控件时偶然发现了答案。W3 HTML 规范定义了一个“成功控制”，如下所示：
一个成功的控件对于提交是“有效的”。每个成功的控件都将其控件名称与其当前值配对，作为提交的表单数据集的一部分。成功的控件必须在 FORM 元素中定义，并且必须具有控件名称。
换句话说 - 一个成功的控制是将它作为查询字符串参数返回到服务器的控制。现在，如果控件没有有效值，则根据规范：
如果在提交表单时控件没有当前值 ，用户代理不需要将其视为成功的控件。
（在这里用“不需要……”来发现“开放解释”的语言）
因此，我认为通过发送 null 而不是空字符串，它可以减少某些浏览器可能发送Foo=&Bar=而其他浏览器甚至可能不发送该查询字符串参数的浏览器不兼容性。总是解释Foo=为好像 Foo 根本不在那里，这会迫使你更加防御。
我认为我至少对于这里的原因是正确的 - 至少部分与“成功控制”的概念有关。