MVC模型最佳实践——如何处理非用户输入数据
所以，我的问题是我有一个模型。我的模型有一些数据是根据通过 url 传入的 id 填充并设置到 cookie 中的，其余的是用户输入，使用数据注释进行验证。
我遇到的“问题”是如何处理这些非用户输入数据。我是否将其放入隐藏控件中，从而增大（尽管只是轻微）我的页面大小，或者我是否在每次回发时“重建”模型的该部分，这会增加另一次数据库往返次数。
我知道这是主观的，但我很好奇标准做法是什么。将数据放入隐藏字段是最简单的方法，但是仅仅为了将其恢复而取消视图状态感觉并不正确，即使是小块。另外，这会将您的数据暴露给用户 - 并不是说他们无法调整网址。没有人喜欢不必要地访问数据库。
哦，我不能使用会话。该应用程序在负载平衡的环境中运行。
So, my question is that I have a model. My model has some data that is populated based on the id passed in through the url and set into a cookie, and the rest is user input, which is validated using data annotations.
The "problem" I've come across is how to handle this non user input data. Do I put it in hidden controls and thus inflate (albeit only slightly) my page size, or do I "rebuild" that part of the model on each post back, which adds another trip to the database and back.
I understand this is subjective, but I'm curious as to what the standard practice is. Putting the data in a hidden field is the simplest way, but it doesn't feel right to have done away with viewstate only to bring it back, even if in small chunks. Plus that exposes your data to the user - not that they couldn't tweak the url. And no one likes unnecessary trips to the database.
Oh, and I can't use session. This app runs in a load balanced environment.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
只需将 id 留在 url 中即可。无论如何，url 都应该识别资源，因此从 url 中取出参数并以任何其他方式存储它只是做额外的工作，并使您的 url 无法识别您正在访问的资源。
如果您还有其他需要发送的数据，通常的做法是在隐藏字段中发送标识符，并像任何其他字段一样对其进行验证。如果您可以推断出信息服务器端的情况，那么就可以归结为权衡重建数据与更大请求的成本。您必须在测试期间衡量哪一个更适合您的应用程序，但这两种方法在实践中都很常见。当您做出决定时，不要忘记安全问题，但这并不全是性能。
另外，如果数据来自客户端，无论您认为隐藏它有多聪明，它仍然是用户输入。这意味着即使您没有为他们设置控件来编辑屏幕上的值，半精明的用户也会知道如何更改它。
Just leave the id in the url. A url is supposed to identify a resource anyway, so taking the parameter out of the url and storing it in any other way is just doing extra work and making your url not identify the resource you are accessing.
If you have other data you need to send, it is very common practice to send an identifier along in a hidden field, validating it just like any other field. If you can deduce the information server side, it comes down to weighing the costs of rebuilding that data vs a larger request. You have to measure which is better for your application during testing, but both are common in practice. Don't forget about security concerns when you make your decision however, its not all performance.
Also, if data comes from the client, no matter how clever you think you are in hiding it, it is still user input. That means even if you don't put a control for them to edit the value on the screen, an half savvy user will know how to change it.
我不认为视图状态是正确的选择，因为它会将内部数据暴露给浏览器，并且还会不必要地增加您的流量。
如果我必须解决这个问题，我会选择使用会话来存储此类与会话相关的数据。如果是负载平衡的环境，您将需要分布式会话处理。解决此问题的最简单方法就是启动 ASP.NET 状态服务并开始使用它来处理会话。
如果您不喜欢 Microsoft 技术，您还可以使用 MemCached 在 memcached 服务器中存储会话数据。有它的提供程序，例如 this，不幸的是它似乎没有在开发中不再有。
I don't think the viewstate is the way to go, as it exposes internal data to the browser and it also increases your traffic unnecessarily.
If I had to solve this problem, I'd go for using the session for storing such session-related data. If it is a load-balanced environment, you will need distributed session handling, tho. The simplest way to solve it is simply starting an ASP.NET State Service and start using it for handling the sessions.
If you don't like Microsoft tech, you can also use MemCached for storing session data in memcached servers. There are providers for it, for example this, unfortunately it does not seem to be in development any more.
如果您能从每个 DAL 中获取它，那就更好了，
在你的 html 中放入不需要的东西是不好的，
想象你得到一个用户并将他的密码放在隐藏的输入中，只是因为你不想每次都得到它。
或者你把一些东西放在隐藏的输入中，并使用firebug有人改变了这些输入的值。
it is going to be better if you will get it from your DAL on each,
it's not good to put unneeded stuff in your html
imagine you get a user and put his password in a hidden input, just because you don't want to get it each time.
or you put some stuff in hidden inputs and using firebug somebody changes the values of those inputs.