MVC Model best practice - How to handle non-user-input data

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 h开发者_如何学Candle 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.

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.

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.

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.