ViewState Caching
This is a great idea, but it's implemented for SharePoint. Wonder if there is a solution for regular asp.net pages, which does the same, caches viewstates.
It's actually quite simple! You just need to override these two methods on your page:
SavePageStateToPersistentMedium()
LoadPageStateFromPersistenceMedium()
In there, you can get the ViewState object tree, serialize it however you want and store it wherever you want (Session, SQL, etc), and instead of returning the entire serialized blob to the browser, just return a unique ID you can use to look it up again next time around.
The idea is covered in painstaking detail here: http://msdn.microsoft.com/en-us/library/ms972976.aspx
It is quite possible through overriding the below two methods in
asp.net System.Web.UI.Page:
SavePageStateToPersistentMedium()
LoadPageStateFromPersistenceMedium()
While in the first method you need to check if the ViewState already exists in the cache and if not save it there, in the second method you can retrieve it if it is already there.
You can concatenate the SessionID and the pageName as the key for the cache viewStateKey.
Related
I am trying to find a specific key within the current Cache.
Problem is, my key in the cache are composite, and I would like to run like a Linq Where expression.
Is this possible? if so - how? does it reduce performance on the server?
Thanks
The whole idea behind a key is that it enables direct lookup of the item. If you have to scan all the items in the cache to find what you're looking for that's not going to perform very well at all. If you're using AppFabric Caching you can "tag" similar items with the same tag and then pull back all the items from the cache with that "tag" with a single call, but there is no such concept in the built in standard ASP.NET caching classes.
We use Page.ParseControl to interpret a string of XML into controls. Does it use some kind of caching mechanism? If not - is there a way to cache its result?
Page.LoadControl seems to support some sort of caching.
There does not seem to be any caching involved.
As a Control is a reference types, caching wouldn't be recommended in this case. (You want a new instance of the control each time you call the ParseControl function)
LoadControl doesn't perform caching per say, but the difference is rather that ParseControl will parse the input string every time to create the control dynamically, while LoadControl will re-use the parsed control template and class type when creating new instances, making it an order of magnitude faster.
This is quite a lengthy post, so bear with me. I'm not sure whether it is primarily about ASP.NET Session State behaviour, NInject, application design, or refactoring. Read on and then you can decide... :-)
Background
First, a bit of background. We are working on trying to refactor a large webshop into a more maintainable , structured design. The webshop is currently running on .NET 3.5, but the design is more of a hangover from the classic ASP days. Obviously we cannot tackle everything in one go, so many of the features / technologies / approaches have to be taken as a given. With that in mind...
The app maintains everything to do with the current session (user profile, cart, session choices, etc.) in a context object which is simply a large XML document that gets serialized to and deserialized from the Session as a string. The XML format is also important because the rendering is done via XSLT.
This has led to a number of problems :
It's a kind of God object with far
too many concerns.
It's loosely typed and relies too much on XML manipulation / XPath.
There is no standard way / pattern for retrieving the session xml document or for writing it back. We have a horrible mixture of methods that take the document in as a parameter, modify it and return it, methods that retrieve it themselves, modify it and save it back to session, etc, etc. This has lead to a lot of hard to trace bugs, over-use of serializing /deserializing from the Session, etc.
Our Solution
What we have done is try to introduce a strongly -typed wrapper around the xml document, which breaks it up into different concerns and to manage the lifecycle transparently to the rest of the app.
What we are aiming for is the following workflow:
Beginning of the request, we populate
the session document from the xml
string stored in the session.
The rest of the app interacts with it
only through the strongly typed
wrapper. The whole app uses the same
instance and does not have to worry
about when to retrieve or save the
state back to session.
At the end of the request, the underlying xml document is serialized back to the Session.
Since we are using NInject(v1) as the IOC of choice, we decided to use this to manage the lifecycle of our context object. The context object was wrapped with the OnePerRequest attribute and the dispose method was hooked up to a method that would save the xml document back to Session as a string.
It doesn't work...
We soon encountered a problem that the NInject OnePerRequest module didn't appear to have access to SessionState. The first thing we tried was a hack that we would keep the Session object in a variable to make sure we could still write to it. This appeared to work on a development machine but it became obvious it didn't when moving to out of process state.
It still doesn't work...
We tried inheriting from the OnePerRequest behaviour / module, and adding the IRequiresSessionState marker interface (OnePerRequestRequiresSessionState). However, this was not enough as the method which NInject uses to release references and clean up gets hooked up to the EndRequest method. Session is available in EndRequest but it has already been serialized to the out of process state server so changing something now is not reflected when the session string is retrieved at the beginning of the next request.
We then decided to change the even t to hook up to. We ditched EndRequest and hooked up our OnePerRequestRequiresSessionState "release all" method to the PostRequestHandlerExecute event, which is BEFORE the session data gets serialized out of process.
It works... then it doesn't...
This seemed to work. On a single server and on a web farm. Then we noticed weird behaviour. There seemed to be two different versions of the context and you would randomly switch between them. Add something to the cart, it's not there. Go to browse to another product and the previous product would show up in the cart.
After some tracing, we discovered the culprit: Response.Redirect. Sprinkled throughout the site in literally hundreds of places is Response.Redirect(url);. With this version of the redirect, the execution of the page is stopped immediately. This means that PostRequestHandlerExecute is not fired and the current version of the Context object is not thrown away by NInject... and everything falls apart. New versions are not created properly, etc. EndRequest is fired which is why the normal NInject OnePerRequest module works fine with it, just not our bastardized version that tries to use session state.
Of course, there is an override to Response.Redirect where you can pass a boolean value in to tell it whether to terminate the existing page or continue to execute - Response.Redirect(url,false). Continuing obviously fires our event and everything works but... it continues to execute the rest of the page! This means executing everything that comes after the call to Redirect and we have absolutely no idea what that means (since the existing site expects it to stop).
What next?
So, any suggestions on what to do? So far we've discussed :
Abstracting our redirect behaviour
and going through a central method
that controls the redirect (perhaps
hacking out a way to call the
PostRequestHandlerExecute even t or
maybe a custom Redirect event that
our NInject module can also
subscribe to and clean up).
Seeing if there is a way we can
force the Session object to save in
EndRequest if it hasn't been saved
previously in
PostRequestHandlerExecute, and do
the ninject clean up in EndRequest
Remove our dependency on Session
completely and use another storage
mechanism: DB, document DB,
distributed HashTable, etc. Any
advice? Suggestions we haven't
thought of? Things you've tried
that have / haven't worked?
I think you're on the right track. Here's some thoughts I had:
in addition to the strongly typed wrapper you have, I'd suggest a facade for accessing the context object that returns your wrapper, something like an IContextProvider. that way you can introduce it piece-meal, and then when it's fully integrated, you can refactor the provider without breaking the things that use it. I can't tell, but you might have already done this. it'll also be easier to change your persistence mechanism if you choose to. if you can do this, I would suggest once you get all the dependencies isolated from the context object, change it to not persist as XML. the SessionState will store a binary object much faster, and you can always serialize to XML if you need to do transforms.
I don't think that Ninject is the correct mechanism for what you're trying to do. it's difficult to signal end of the request in Ninject, since garbage collection can't be depended on. have you considered using an IHttpModule instead? you can use the AcquireRequestState and ReleaseRequestState or EndRequest to handle getting/setting the context in Session. only allow the app to get to the context object through the facade.
if you're on a webfarm, you're probably using a database for your Session storage anyway, so putting your context into a DB won't be much different.
Firstly, while it's good to demonstrate you've put in the work, (and I and others may not have replied if it wasn't clear how much you're interested in a resolution)... that's a massive wall of text! Here's a +1 on your way to investing in a bonus for a complete response that talks about the Ninject ASP.NET extensions and how they apply to each individual element of your issue. Having said that, hopefully someone will come along with a real resolution for you.
Even though it's [very] 2.0 specific, Nate's Cache and Collect Post is required reading. While it seems you're pretty au fait with the tradeoffs involved and have debugged deep in, the article is well worth a few reads.
I'd also consider moving to V2 of Ninject - a lot of this stuff has been revised significantly. It's not magically going to work, but represents a mature rewrite based on a lot of learning from V1. Have you read the (V1 or) V2 unit tests for Ninject? They'll show you the low level tools at your disposal in order to realise your goals.
Bottom line for me is that you need to work out a strategy for your state management independent of DI, and then by all means use the container/DI system as a part of the implementation.
I'm sorry for maybe making such a basic question but in ASP.NET websites what does the __VIEWSTATE input field represent?
Also, is there any way to compute it's value (based on the values of other form fields)?
EDIT
I understand that __VIEWSTATE, as the name suggests, maintains the values of form field values in webpages however what I'm interested in knowing is how this state (the string) is generated. If I base64_decode any __VIEWSTATE string all I see is a bunch of cryptic HTML.
Is there any way to better understand what exactly is being encoded? I've searched on past questions and I've found some tools that can do this like this one, but unfortunately it doesn't seem to work.
The reason I'm asking this is because I've access to a web service API that gives me most of the values I need to work with. However I also need an additional field that is only available on the last stage of the form. I already contacted the web service provider but unfortunately and they're not going to update their API so soon. I was hoping I could prefill the form initial values using the web service data and then calculate the __VIEWSTATE to access the last field that shows up on the last stage of the form, it would make the whole process a lot faster.
Not sure if I made myself clear enough though...
Paul Wilson has a very good article: ViewState: All You Wanted to Know
VIEWSTATE can be deserialized with the LosFormatter class.
A quick Google search answers the question:
http://msdn.microsoft.com/en-us/library/ms972976.aspx
First sentence:
Microsoft® ASP.NET view state, in a
nutshell, is the technique used by an
ASP.NET Web page to persist changes to
the state of a Web Form across
postbacks.
If you really want to understand it well, see Dave Reed's article about ViewState.
Do take a look at the biter script posted at http://forums.techarena.in/windows-software/1329157.htm.
That script shows how to set up and use __ViewState and other .NET variables.
That script logs into a .NET site, and gets stock values, without going thru a browser. Instead of user doing it manually, the script does it programmatically.
What do you mean by compute it's value?
Assume that it is a compressed (actually Base64 encoded) pair of your form fields/values in text form, which gets serialized into server side objects for you to work with.
The easiest way of doing this in Razor is putting this on a view:
#{
throw new Exception();
}
I have been using Request.Form for all my code. And if I need querystring I hit that explicitly too. It came up in a code review that I should probably use the Params collection instead.
I thought it was a best practice, to hit the appropriate collection directly. I am looking for some reinforcement to one side or the other of the argument.
It is more secure to use Request.Form. This will prevent users from "experimenting" with posted form parameters simply by changing the URL. Using Request.Form doesn't make this secure for "real hackers", but IMHO it's better to use the Form collection.
By using the properties under the request you are narrowing down the your retrieval to the proper collection (which is a good thing for readability and performance). I consider your approach to be a best practice and follow it myself.
I have always used
Request.Form("Param")
or
Request.QueryString("Param")
This is purely down to a syntax which is easier to read. I seriously doubt there is a performance impact.
The only time I use Request.Params instead of Form or Querystring is if I don't know whether the method by which the parameters will be passed in.
To put that in context, in 10 years I have used Request.Params in anger only once :)
Kindness,
D
I think it's better to use the Form and QueryString collections explicitly unless you're explicitly trying to define flexible behavior in your application like in a search form where you might want to have the search parameters definable in a URL or saved in cookies such as pagination preferences.
I would use Request.Form and Request.QueryString explicitly. The reason is that the two are not interchangable. The query string is used for HTTP Get requests, and FORM variables for HTTP post requests.
Get requests are typically applicable where you are requesting data, e.g. do a google search, the search words are in the query string. The post are when you are sending data to the web server for processing or storing. So when I say that the two are not interchangable I mean that you cannot change the page from using a GET to a POST without breaking functionality.
So IMHO, the implementation of the page can quite clearly reflect the fact that you intend it to be called by a GET or a POST request.
/Pete