MVC - 在请求之间保留视图模型数据
我正在寻找一些建议或可能是我忽略的解决方案，以解决我正在从事的项目中遇到的问题。它涉及在多个请求之间保留 ViewModel 数据。下面是一个示例：
用户位于包含一些表单字段和与底层模型相关的项目网格的特定页面上。用户需要向网格添加一个或多个项目，因此我必须将它们重定向到另一个页面以选择其中的一些项目。用户在此页面上选择项目后，我需要将它们发送回原始页面，项目显示在网格中。
我已经完成了这项工作，但我正在做的是在将它们重定向到第二页之前，我将原始页面的 ViewModel 存储在会话中，使用第二页上的所选项目适当更新 ViewModel，然后重定向回原始页面并使用会话中的 ViewModel 来填充表单字段和网格。
但是，我认为这不是最好的解决方案，并且可扩展性将成为一个问题，因为该项目需要可扩展，并且在会话中乱扔东西并不是理想的解决方案。我已经阅读了大量建议的类似问题，但我没有发现任何真正适合我的具体情况的内容。
有没有人做过这样的事情并找到了更可靠的解决方案，或者可能对不同的实现有一些建议。谢谢。
I am looking for some suggestions or possibly a solution I've overlooked for an issue I have with a project I am working on. It involves persisting ViewModel data between several requests. Here's an example:
User is on a specific page that contains a few form fields and a grid of items related to the underlying model. The user needs to add an item or items to the grid, so I have to redirect them to another page to select some of these items. After the user has selected their items on this page, I need to send them back to the original page with the items displayed in the grid.
I have this working, but what I'm doing is before they are redirected to the second page, I am storing the ViewModel for the original page in session, updating the ViewModel appropriately with the selected items on the second page, then redirecting back to the original page and using the ViewModel from session to populate the form fields and grid.
However, I don't think this is the best solution and scalability is going to be an issue since this project needs to be scalable, and throwing stuff around in session is not a desired solution. I've read the multitude of suggested similar questions but I've found nothing that really pertains to my specific situation.
Has anyone ever done anything like this and has found more reliable solutions, or possibly has some suggestions on a different implementation. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这归结为基本的网络请求限制，并且每个请求本质上都是“重新开始”。 Session 的构建绝对是为了让您有一个地方可以存储请求模型之外的内容，并且是您唯一的选择，除非您想使用 javascript 采用更高级的方法。
查看这篇文章作为我已经介绍了编辑列表的主要解决方案，其中一些适用于此处。
在你的情况下，我肯定会建议使用模式/对话框弹出窗口来选择你的“其他”项目，因为这将消除你完全离开页面时遇到的大部分麻烦（如果该页面在其他地方使用，您可以轻松地重复使用部分视图，使其在对话和页面中工作而无需重复）。
这将涉及一点 JavaScript，但会更容易管理，因为表单实际上会保留在页面上，并且在我遇到的大多数情况下，这是更好的用户体验。
或者，您需要在其他页面上使用隐藏的输入，并通过选择过程发布您的数据。看不出有多少方法可以让这件事不会变得丑陋。
总之，如果您不想制定客户端解决方案，那么使用会话是唯一的选择。我推荐客户端解决方案，因为 jquery 使我们的生活在这些场景中变得更加轻松，但它更复杂。
PS 如果您确实认为对话不是最佳选择并坚持使用会话，请不要担心它的可扩展性，因为您可以通过使用其他会话存储方法（例如状态服务器，甚至是专用的 SQL 数据库）来使其更具可扩展性。它。
This comes down to a basic web request limitation and every request being essentially "starting again". Session is definitely built to allow you a place to store things beyond the request model and is your only option UNLESS you want to take on a much more advanced approach using javascript.
Checkout this post as i have already covered off the primary solutions for editing a list and some of that applies here.
In your case I would definitely recommend using a modal/dialogue popup for selecting your "other" items as this will remove most of the hassles you'll encounter by navigating away from the page completely (and if that page is used in other places, you could easily re-use partial views to make it work in a dialogue as well as a page without duplication).
This will involve a little javascript, but will be much easier to manage as the form will actually stay present on the page and in most cases I've encountered is a better user experience.
Alternatively you'd need to use hidden inputs across the other pages and post your data around through the selection process. Can't see many ways that this won't get ugly.
In conclusion, using session is the only option if you don't want to make a client side solution. I'd recommend the client solution as jquery has made our lives much easier for these scenarios, but it is more complicated.
PS If you do decide the dialogue is not the best option and stick with session, don't panic about it's scalability as there are ways you can make it more scalable by using other session storage methods like state server or even a dedicated SQL db for it.