我正在使用AcceptVerbs
Scott Gu的Preview 5博客文章中详述的方法来处理ASP.NET MVC中的表单条目:
用户通过GET获取一个空表单
用户通过POST将填写的表单发布到同一个Action
操作验证数据,采取适当的操作,并重定向到新视图
所以我没有必要使用TempData
.也就是说,我现在必须在此过程中添加一个"确认"步骤,似乎需要使用TempData
.
出于某种原因,我厌恶使用TempData
- 它是一种可以设计的东西.
这是一个有效的问题,还是我在弥补?
无需厌恶TempData ......但如果使用不当,肯定会表明设计不佳.如果您使用的是RESTful URL,则TempData是将POST操作中的消息传输到GET操作的最佳实践.考虑一下:
您在URL Products/New有一个表单.表单发布到产品/创建,验证表单并创建产品,成功时,控制器重定向到URL Products/1,出错时将重定向回产品/新建以显示错误消息.
Products/1只是产品的标准GET操作,但我们希望显示一条消息,指示插入是成功的.TempData非常适合这种情况.将消息添加到Post Controller中的TempData,并在视图中放置一些if逻辑并完成.
失败时,我一直在在PostFollection中添加输入的值,并在Post Action中添加错误消息到TempData,并重定向到初始Action Prodcuts/New.我在视图中添加了逻辑,用以前输入的值和任何错误消息填充表单输入.对我来说似乎很干净!
我认为你在使用TempData之前犹豫不决.TempData存储在会话中,如果出现以下情况,这可能会对您产生影响:
您现在不在自己的网站上使用会话
您有一个需要扩展到高吞吐量的系统,即您更愿意完全避免会话状态
你不想使用cookies(我不知道MVC现在支持无cookie会话的程度如何)
如果您的站点需要具有高可用性,那么在应用会话状态方面还有其他注意事项,但这些都是可解决的问题.
我认为临时数据是一种用于通知用户的"即发即忘"机制.很高兴能让他们提醒他们最近做过的事情,但我也犹豫是否要在某些用户流程中采取必要步骤.原因是如果他们刷新页面,我相信它会消失.嗯,我想我也犹豫是否使用它,因为它没有真正明确的可靠性.
我想知道问题是你在确认步骤之前将操作重定向到另一个页面.我想知道在他们第一次提交之后,你可以做足够的处理来生成确认对话框,然后返回带有确认问题的原始页面.与验证方法类似,但验证规则检查是否执行了确认步骤(确认UI隐藏,直到其他验证通过).