MVCContrib 网格并使用模型绑定器回发
我的 MVCContrib 网格的内容来自强类型视图上的模型。 当发布帖子时，当它返回到控制器时，网格的内容不在模型对象中。 我可以看到这是因为网格呈现为一个表格，单元格中包含文本。 我可以做些什么，以便当帖子发生时，我发送到网格的列表数据会在帖子中返回？
The contents of my MVCContrib grid come from the Model on a strongly typed View. When a post is made, the contents of the grid are not in the model object when it returns to the controller. I can see that this is because the grid renders as just a table with text in cells. Is there something I can do so that when the post occurs, the list data I sent down to the grid comes back in the post?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以使用 TempData 将此信息保留在服务器端。 TempData 中的信息将在一次请求中持续存在。 不过我不太喜欢这个选项。
您不能从数据库重新填充您的模型吗？ 如果用户没有更改信息，为什么您需要回发所有相同的未更改信息？ 只需从之前获得它的地方再次抓住它即可。
You can use TempData to persist this information server side. The information in TempData will persist for one request. I do not really like this option however.
Can you not repopulate your model from the db? If the user is not changing the information why do you need to post back all the same unchanged information? Just grab it again from where you got it before.
如果您想在序列化到网格中时重新创建模型，则必须在网格内（或者可能在网格外）嵌入正确命名的表单元素，并且在与包含回发到的按钮的表单相同的表单内您希望在其中重新创建模型的操作。
虽然这是可行的，但您本质上是在重新创建 __VIEWSTATE，这会破坏使用 MVC 的大部分乐趣（请阅读“这是一个丑陋的黑客行为，您应该卸载您的 IDE，即使想到它”）。
如果不更好地理解您要解决的场景，就很难为您指明正确的方向。 这些情况下的通常工作流程是
获取模型
页面上的表单
从帖子到模型
如果您遇到性能问题（您已经证明您遇到了性能问题，对吗？您没有过早优化？），请在问题发生时解决它们（即在数据访问中缓存），而不是以不应该的方式扭曲 MVC。
If you want to recreate the model as it was serialised into the grid, you will have to embed correctly named form elements within the grid ( or maybe outside the grid ) and within the same form as the one containing the button that is posting back to the action where you want your Model recreated.
While this is doable, you are essentially recreating __VIEWSTATE, and that defeats much of the joy of working with MVC ( read "it's an ugly hack and you should uninstall your IDE for even thinking it").
It is hard to point you in the right direction without having a better understanding of the scenario you are trying to solve. The usual workflow in these situations is
get the model
form on the page
from the post into the model
If you are suffering performance issues ( you have proved you've got a perf problem right? You aren't optimising prematurely?), address them where they occur ( i.e. caching in your data access ), rather than bending MVC in ways it really shouldn't be.