@C-Octothorpe said:
Are you trying to sound like a complete ass, ....
I respectfully withdraw from this conversation - not sure why it went wrong but there you go.
@C-Octothorpe said:
Are you trying to sound like a complete ass, ....
I respectfully withdraw from this conversation - not sure why it went wrong but there you go.
@C-Octothorpe said:
@Sutherlands said:
@callcopse said:To be fair to callcopse, Session can be stored in a number of ways. If it's in-process, then it's blazing fast and you're only limited by server memory. Then there is state server, which IIRC is sent via binary serialization to another server, also a very fast method of session storage. The other common one is SQL session state, which can be slow as it's a trip to the DB on the request, deserialize, [page lifecycle here], serialize and send back to DB, but scales well to a web farm.Why is a large ViewState ok, but a large Session is not? I'm not much of a webdev, but it seems to me that ViewState gets sent over the wire with each request, and a session gets saved on the server? If that's the case, it seems like (depending on load/memory) big session would allow it to perform a lot quicker than sending the info over the wire each time.I'm not saying use ViewState == Session - you lot had brought ViewState into it. I'm saying in terms of trade-offs I can sometimes accept heavy ViewState (say 100 - 200K/page these days is not unreasonable) however when it comes to Session, none to miniscule is all I prefer to see.
I'd also like to point out that callcopse *is* equating the two simply by saying he would rather have a large ViewState vs. large Session object.
Either way, I'm curious as to why you think Session is so much worse than ViewState. Me thinks you read a single article proclaiming the virtues of ViewState over Session without performing any critical thinking after reading it.
Well, I am simply comparing the two evils, not saying one is used for the same purpose as the other, which you kind of implied as a bit of a sneaky dig. In-process session is not a great idea if there is any likelihood of app recycling - like there might not be on shonky old IIS. That leaves DB or Service State. I guess it is personal preference and shop working practice, and perhaps a hang over from classic ASP, days but leaving 'rich' stuff in DB session when you might just recreate seems rather pointless, and I prefer to avoid even a whiff of overwhelming State service. I don't 'prefer' large ViewState just sometimes don't think it the end of the world. Depending on usage.
In terms of the 'recreate' above a rich object can be serialised / de-serialised from DB pretty simply, and it's a technique that is very effective - never missed a beat in doing that kind of thing (Usual provisos about updating object model etc)
Are you making a case for loading session more heavily? Guess you might not have seen the fairly non-l33t servers we get to use...
@Sutherlands said:
comprehension fail?
But hey, let's take the entire page and cram it in the viewstate. No need to worry about the client uploading 500KB/multiple MBs back to the server, right? Everybody has a good connection, Shirley.
What I mean is - if you're liable to go in all attack dog on a shy little users first post you could at least spell properly. (Post <> Past).
I'm not saying optimising page load is stupid, just that it is premature in some cases, and modern grids often do have a high impact on ViewState. Sometimes you might want to do something about that, other times who gives a flying one? (e.g. Only occasionally used by users logged in from business connections etc).
I'm not saying use ViewState == Session - you lot had brought ViewState into it. I'm saying in terms of trade-offs I can sometimes accept heavy ViewState (say 100 - 200K/page these days is not unreasonable) however when it comes to Session, none to miniscule is all I prefer to see.
OK?
@C-Octothorpe said:
Isn't that what ViewState is for? Really, show me a single developer who wouldn't feel accomplished when you have IIS shittting out pages in the 500k size range?
Depends upon the target audience. If for general users I'd try and keep it down from that for sure. It's not a diasaster for a complex application though aimed at users on an extranet. It's a compromise between using fancy grid type controls and spending the extra time to make it all spiffy - for an admin page I'll say just use the fancy dan controls and accept the ViewState hit, for a central data entry type page I'll try and be a bit more optimised.
I'll always take the ViewState hit over Session though - it is occasionally necessary to use Session but sparely and for integers alone ideally.