Scott Hanselman

Moving ViewState to the Session Object and more Wrongheadedness

February 28, '04 Comments [5] Posted in ASP.NET | ViewState
Sponsored By

Some folks didn't agree with my recent comments on ViewState.  That's cool, it's good to disagree.  The truth is no doubt somewhere in the middle.  My conclusion, and your take away should be this:

  • ASP.NET sucks exponentially LESS than any previous Web development technology
  • ViewState can be used for evil, but if you understand it, it can be VERY useful
  • ASP.NET is so powerful that it can enable you to be an incredibly bad programmer FASTER THAN EVER.  Don't program by coincidence. 
  • Know the bytes that leave your web server and what they are for.  Look inside the Viewstate with either Web-based Paul Wilson's ViewState Decoder, or Fritz Onion's Win-Form ViewStateDecoder.
  • Buy Fritz's book.  Seriously.

Now, that being said, I've also seen lots of talk on the 'Net about overridding default behavior and storing ViewState to another location, like the Session object.

Sadly, I saw lots of code on the USENET like this (Here's a VB.NET Example, but the language is an implementaton detail):

Public Class PageViewStateSession
    Inherits System.Web.UI.Page
  Protected Overrides Function LoadPageStateFromPersistenceMedium() As Object
    Return Session("ViewState")
  End Function
  Protected Overrides Sub SavePageStateToPersistenceMedium(ByVal viewState As Object)
    Session("ViewState") = viewState
    RegisterHiddenField("__VIEWSTATE", "")
  End Sub
End Class

What's wrong with this?  Apparently not enough to keep it off the 'Net, but enough for me to remind you:

Scott's Rule of Programming - Rule# 0x3eA
Just because code is on the Internet doesn't mean you should cut and paste it into your production system.  Do you chew gum you find on the street?  Give code you find on the 'NET the same amount of attention you'd give advice scrawled on a public bathroom wall.

What's wrong with the code?  Well, it uses the SAME KEY to store the ViewState in the Session object, forgetting that ACTUAL ViewState stays with the page 'instance.'  To use an anology you can relate to, just pick a random variable in any application you wrote and slap the keyword static on it.  Think it will work?  If it does, I wonder how long it will? 

If you store ViewState in the Session object in this way, you are assuming the user will access only one page at a time, and you may confused other pages in their attempt to load values from Bogus ViewState.  More importantly, what happens if the user opens new browser window, and starts accessing DIFFERENT pages but sharing the same session.  Well, you get the idea.

Some folks got around this by adding the requested page to the ViewState key:

Session[this.Request.Path + "-VIEWSTATE"] = ViewState;

But remember that the actual code in ASP.NET (more or less, via Reflector) does this:

text1 = this._requestValueCollection["__VIEWSTATE"];

It pulls the ViewState from the request NameValueCollection (including the Form collection, etc).  Each 'instance' of a page has it's own ViewState.   Then in OnFormRender, they:

writer.Write("__VIEWSTATE");
writer.Write("" value="");
this._formatter.Serialize(writer, this._viewStateToPersist);

So the question of the day is, how to move ViewState in to the Session Object (conveniently ignoring the additional memory consumption and the fact that the objects you store in the session will not expire, eh?), but still allow a user to have TWO browser windows up acting on the same page at the same time?  You'd need to store a unique index key in a Hidden Field to act as a lookup into the Session object rather than using the name of the page.

Here's the only even-close-to-clever example I could find via Google, and it has a LOT of limitations and a LOT of moving parts, and may have some threading problems. (Remember the bathroom wall!)

Even More Conclusion

Seems to me that this is a lot of work to do to save a fer bytes when someone could just:

  • Learn what needs ViewState and what doesn't and use it selectively.  It's NOT required for 90% of things, and you can usually get it down to a very small size.
  • Spend less time writing wrongheaded plumbing code to replace ViewState, and instead learn how to use it effectively and efficiently.  Read that last sentence again.
  • If you're that worried, use HttpCompression (seriously, if you're not using Http Compression, what's your excuse?)

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Microsoft's "Whitehorse" - Visual Design back in Vogue?

February 27, '04 Comments [1] Posted in Corillian | ASP.NET | XML | Web Services | Bugs | Tools
Sponsored By

Hey, I was quoted in a 'Whitehorse' article on CNET that's mirrored at ZDNET.

Financial software maker Corillian, for example, said Microsoft's services-oriented approach with Whitehorse and the close synchronization between application models and the code that corresponds to them will yield higher-quality code and help development teams stick to an application's original design, said Corillian chief architect Scott Hanselman.

"You want to fix bugs in design. The closer you get to the go-live date, the more expensive a bug is," Hanselman said.

Whitehorse should also help developers create software more quickly, he said. The combination of the tool's Web services assembly approach and the prewritten chunks of code that Microsoft provides "gives me bigger and bigger Lego blocks than I've ever had to play with before," Hanselman said.

That's more or less what I said. :)  Of course, taken in snippets things like 'find and fix bugs early' sound cheesy to the trained ear, but it's still worth the saying.

I always thought the Visio integration into the Visual Studio.NET Design/Development process was a little iffy and it never really took off for me.  The project 'Whitehorse' will introduce a new series of graphical designers in Whidbey (the next version of Visual Studio.NET) with support for design and validation of Web Services-based systems.  The Toolbox will include a 'Visual Service Designer' that will include a whole series of visual representations of different services.  A conceptual service might be a Web Servuce, a Database, an ASP.NET Web App, etc.

I think they'll get it right this time.  Just a feeling.  A lot of good thought has been put into this feature, and with the emerging WS-I standards, and all the good thought around SOA, all the ingredients are here.

P.S. I can only imagine that the stuff the guys at Mindreef (makers of the SOAPScope product that you should buy) will cook up to integrate with these new designers. 

Be sure to check out the MSDN TV Episode featuring Whitehorse.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Changing the Font Size of the Reading Pane in Outlook 2003: Impossible?

February 25, '04 Comments [10] Posted in Musings
Sponsored By

Is it sadder that:

  1. You can only change the font size for the Reading Pane in Outlook 2003 by right clicking the tiny grey border around the Reading Pane.
  2. When you do click the menu item then move to another email, the option switches back to Medium for the next message.
  3. The menu items have no effect (the font sizes don't change) on 90% of corporate mail including RTF and WordMail.

Is this totally broken or am I totally broken?

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

DCOM deserves our respect

February 25, '04 Comments [1] Posted in Web Services
Sponsored By

I thought it was cool that noone commented negatively (as well they shouldn't) when the very prolific Chris Brumme said in his recent post on Apartments and Pumping in the CLR:

In general, I love OLE and the folks who work on it.  Although it is inappropriate for the Internet, DCOM is still the fastest and most enterprise-ready distributed object system out there.  In a few ways the architecture of .NET Remoting is superior to DCOM, but we never had the time or resources to even approach the engineering effort that has gone into DCOM.  Presumably Indigo will eventually change this situation.  I also love COM’s strict separation of contract from implementation, the ability to negotiate for contracts, and so much more.

A lot of folks just knee-jerk and say "DCOM Sucks" and that's not justified.  A while back Clemens said:

Enterprise Services has a very elegant solution for mixing the two models in that it uses Remoting to do almost all marshaling work (with two exceptions: QC and calls with isomorphic call sigs) and then tunnels the serialized IMessage through DCOM transport, which means that you get full CLR type fidelity while using a rock solid transport that has been continuously optimized ever since 1993. I understand that some people consider a 10 year old protocol boring; I just call it "stable".

Preach on my brothers.  In this time where software innovates at lightening speed, some younger and short-sighted developers may thing a 5 year old OS or 10 year old protocol are 'out of date.' 

At Corillian, while our Voyager platform has supported .NET since .NET's inception and supports WS-I compliant Web Services, the core application still uses DCOM for inter-machine communication on the inside of the firewall.  And Voyager still runs [quite possibly] the largest single instance Banking Web site in the world.  It scales quite nicely, thank you, and due to people who came before me.  I poo-pooed DCOM when I came to work at Corillian 3 years ago.  And while I've worked on Voyager these past years, building .NET abstraction layers on top of it, hosting the CLR within the product, and communicating with all breeds of mainframes, DCOM has done it's job nicely as a transport between our distributed services.

Remember my friends (that means you VB guys also) that due to the work of a lot of OLE people 10 years ago, your crown has been paid for.  Now put it on.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

ASP.NET ViewState: Pox on mankind? Or clever like a fox?

February 24, '04 Comments [3] Posted in ASP.NET | Javascript | ViewState | HttpModule
Sponsored By

A good friend of mine (who may or may not reveal himself by trackbacking this post) emailed me recently, with reference to my post on ASP.NET ViewState. 

He had some interesting opinions, so here are some choice snippets reprinted with this permission, with my commentary interlaced:

IMHO viewstate is the second worst piece of the .NET Framework. The worst being "javascript:do_postback" instead of providing clean, lean and mean URLs. Oh wait, they are related -- the latter is the necesary workaround for the former.

I think it's actually damned clever, and quite possibly neccesary.  The HTTP/HTML combination needed an eventing subsystem built on top of it.  DoPostback() does just that with support for Event Targets and Event Arguments.  It's simple, supported, and clean.  POSTing data (rather than GETting) is needed, nay, required to move stuff from place to place on browser-based web.  I certainly can't be putting on this crap in my URLs, can I?  Believe me, I'm all about REST, and I believe the REAL answer lies in both POSTs, and well designed URI/Ls.

Viewstate is bad because I can't set a bookmark to it. Instead of using viewstate, developers who want to create great webapps should pass a querystring parameter for read-only operations. The whole concept of doPostback should be abandoned altogether and developers should instead look up the original HTTP specification which details the ramification of GET vs. POST.

Phooey! :)  Viewstate was needed to allow things like listboxes to POST not just their currently selected item, but also ALL the other items.  Otherwise, how do I reconsitute my listbox on the next go-around?  Better I pay a few BASE64'ed bytes on the roundtrip than head back to the database.

ViewState was just a state bag, and as Brad notes in the comments of the previous post, it can be "normalized" away with a key (I wonder if they are hearing this and will hook it up to ASP.NET Session State in Whidbey?)

Whenever a certain resource is only addressed (and not changed in any way, i.e. whenever the underlying operation is safe), GET should be used so that you allow the user to have a uniform resource locator for this very thing. Just imagine, google.com would use viewstate and such ... you wouldn't be able to address the query for "Scott Hanselman" as http://www.google.com/search?q=%22scott%20hanselman%22. Or the second page on this query as http://www.google.com/search?q=%22scott+hanselman%22&num=100&hl=en&lr=&ie=UTF-8&start=100&sa=N. Now, that would be bad.

Now this I totally agree with.  GETs and "hackable URLs" are totally appropriate for an operation like this.  But for a form that includes my credit card info and full address, not so.  Then add in dropdowns and database-backed grids, then maybe a few buttons...aren't you wishing you had an eventing subsystem and a way to reconstitute your controls? ;)

Second reason for why this whole thing (especially javascript:dopostback) is bad: It doesn't allow me to "Open in new window". I use a tabbed browser and regularily open links in new windows. I find more and more sites which just use ASP.NET and don't handcode their URLs anymore leading to "forced-single-window-navigation."

True, I hate that also.  But, to be clear, my mom, and most folks on the web, don't care.

 But let's get back to the topic: the creation of viewstate and the associated necessity for doPostback instead of <a href=""> have created a bunch of non-standard, non-userfriendly web applications.

Unfriendly is up for debate, but non-standard?  I don't think so.  Last time I checked I had ASP.NET sites up running on 15 different browser variants using doPostback happily and transparently.  If there's a better way that will still give me:

  • Server-side Events (onclick, onchange, etc)
  • Reconstitutes the state of my controls without requiring a call back to the datastore.

Then I'll be the first to code the HttpModules or whatever's required to make it happen.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.