TryUpdateModel 与强类型方法参数

发布于 2024-12-08 12:14:55 字数 677 浏览 1 评论 0原文

在 MVC2 中，我曾经以一种在发布时从未使用过 FormCollection 对象的方式创建强类型视图。我的签名总是看起来像这样：

[AcceptVerbs(HttpVers.Post)] 
public Create(Person newPerson)
{ 
//code to update the person from the post
}

但现在我看到了这种新的 TryUpdateModel 方式，我只需编写如下内容：

    [AcceptVerbs(HttpVers.Post)] 
    public Create()
    { 
        Person thePersonToCreate = new Person()
        TryUpdateModel(thePersonToCreate)
        {
            //Code to create the person if model is valid
        }    
    }

所以现在看来我必须模拟 HTTPContext 才能测试此方法。但是，似乎我仍然可以使用前一种使用强类型方法的方式。我意识到 TryUpdateModel 方法对于那些使用 FormCollection 方法做事的人来说是一种改进，但为什么还要费心使用 TryUpdateModel 呢？

原文

In MVC2 I used to create strongly typed views in a way that when I posted, I never used the FormCollection object. My signatures always looked like so:

[AcceptVerbs(HttpVers.Post)] 
public Create(Person newPerson)
{ 
//code to update the person from the post
}

But now I'm seeing this new TryUpdateModel way where I would just write something like:

    [AcceptVerbs(HttpVers.Post)] 
    public Create()
    { 
        Person thePersonToCreate = new Person()
        TryUpdateModel(thePersonToCreate)
        {
            //Code to create the person if model is valid
        }    
    }

So now it seems I have to mock up the HTTPContext in order to test this method. However, it seems like I can still use the former way using strongly typed methods. I realize that the TryUpdateModel method is an improvement for those who would use the FormCollection method of doing things but why bother with TryUpdateModel?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

短暂陪伴 2024-12-15 12:14:55

在某些情况下这是可取的。一个很好的例子是当您的模型需要更复杂的初始化或工厂方法来创建时。

[AcceptVerbs(HttpVers.Post)] 
public Create()
{ 
    var dataAccess = new MyDataAccess("Another Param");
    Person thePersonToCreate = new Person(dataAccess);

    TryUpdateModel(thePersonToCreate)
    {
        //Code to create the person if model is valid
    }    
}

现在，有人可能会认为自定义 ModelBinder 是一种更好的解决方案，但如果这是一次性情况，那么可能会付出更多的努力而不值得。此外，将此详细信息隐藏在 ModelBinder 中会使错误更难以调试。

我确信还有其他情况，但这只是一个简单的例子。

There are instances where this is desirable. A good example is when your model requires a more complex initialization, or factory method to create.

[AcceptVerbs(HttpVers.Post)] 
public Create()
{ 
    var dataAccess = new MyDataAccess("Another Param");
    Person thePersonToCreate = new Person(dataAccess);

    TryUpdateModel(thePersonToCreate)
    {
        //Code to create the person if model is valid
    }    
}

Now one might argue that a custom ModelBinder is a better solution here, but that might be more effort than it is worth if this is a one off situation. Also, hiding this detail in a ModelBinder makes errors more difficult to debug.

There are other situations I'm sure, but this is just a quick example.

回复收藏 0 原文