p2p.wrox.com Forums

p2p.wrox.com Forums (http://p2p.wrox.com/index.php)
-   BOOK: ASP.NET 3.5 Enterprise Application Development with Visual Studio 2008: Problem Design Solutio (http://p2p.wrox.com/forumdisplay.php?f=477)
-   -   ViewState vs Caching (http://p2p.wrox.com/showthread.php?t=74029)

Corsair April 21st, 2009 04:02 PM

ViewState vs Caching
 
I was wondering if there was a particular reason for choosing to use ViewState rather than cache to store the objects?

The application I'm developing may have lots of information in the objects - just the simple tests I've done so far have take up a large chunk of the page for the ViewState.

Was there a design consideration (that maybe I missed in the book) for this, or was it a personal choice?

Generally, I try to avoid ViewState like the plague (along with Session), so it could be that I'm just unreasonably biased.

Tim

chroniclemaster1 April 21st, 2009 06:06 PM

I agree. ViewState tends to get out of control quickly. I too would be interested to see if there's a reason, or if it just made for easier to understand examples. (That's one of the things I don't like about MSDN is how it explains best practices but then uses SqlDataSource in all the examples.) :(

AspNew April 22nd, 2009 11:49 AM

Using MVC is one way :).

ZeroFactorial April 28th, 2009 03:18 PM

Quote:

Originally Posted by AspNew (Post 239932)
Using MVC is one way :).

The book that Vince has put together is in a nutshell MVC if you compare what he has done against the MVC model.

MVC meaning Model, View, Controller is the same three layer process that Vince followed. The issue of ViewState vs Cache is purely choice and has nothing to do with software architectural pattern. To me they both accomplish the samething.

With that being cleared up and correct me if Im wrong.
To me Viewstate is my preferred choice from a security standpoint. Cache can be comprimised after the page no longer exists. With ViewState it only exists on that one page while that page is present. So if you go to a new page no more data, with Cache you get easier access to the data but it exists until you destroy it.

Corsair April 28th, 2009 04:51 PM

Wouldn't you be able to overcome the security issue with a little extra code? Perhaps in the global.asax's Application_End? Just call Cache.Remove(key) for each item in the cache.

Or set an expiration on the data in the cache (going off the top of my head here; don't remeber the exact way to do that).

For me, unless the page is light on controls and/or data, I prefer to avoid ViewState, but that's just a personal preference. At least until someone convinces me solidly one way or the other. :)

Tim

ZeroFactorial April 30th, 2009 12:17 PM

Quote:

Originally Posted by Corsair (Post 240315)
Wouldn't you be able to overcome the security issue with a little extra code? Perhaps in the global.asax's Application_End? Just call Cache.Remove(key) for each item in the cache.

Or set an expiration on the data in the cache (going off the top of my head here; don't remeber the exact way to do that).

For me, unless the page is light on controls and/or data, I prefer to avoid ViewState, but that's just a personal preference. At least until someone convinces me solidly one way or the other. :)

Tim

Tim you are right, that is why I said that it is more of a preferred thing than a right vs wrong thing. I havent seen anything that is totally against it that had factual backing vs opionated backing.
That is the great thing about programming for Windows and the Windows platform altogether. There are multiple ways to do the same thing.
Have a good one.

DJ

hasanboby April 29th, 2010 05:16 AM

<sessionState mode="Off" />
 
I disabled the session at all. now I can do web farming on my UI layer for scalibility and performance. no need for any state server for session. just compress your view state before storing if you are woried of page size.


All times are GMT -4. The time now is 03:24 PM.

Powered by vBulletin®
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.