ViewState in WebService? Is this possible?

Question

according to my research, it isn't possible... unless i write one big hack (erk) to get around it... im wondering if it is possible or not as some of you may have more information on this. i understand this would go against the page paradigm, however it really should be accessible... any ideas anyone?

hate using cookies as the information is updated and reflects the real values in the collection after a full roundtrip (so always a 1 round trip lag)... im just storing an array really... session can be used in webservices but really dont want to load server up too much, although its probably only half a kb... maybe im just too paranoid?

any advice will be appreciated on if its worth the trouble of not using session state, im currently using cookies, would prefer to use viewstate, thanks.

Answer 1

Why not use the application cache instead? It works great for this purpose.

public static void AddToCache(string key, Object value, int slidingMinutesToExpire)
{
        if (slidingMinutesToExpire == 0)
        {
            HttpRuntime.Cache.Insert(key, value, null, System.Web.Caching.Cache.NoAbsoluteExpiration, System.Web.Caching.Cache.NoSlidingExpiration, System.Web.Caching.CacheItemPriority.NotRemovable, null);
        }
        else
        {
            HttpRuntime.Cache.Insert(key, value, null, System.Web.Caching.Cache.NoAbsoluteExpiration, TimeSpan.FromMinutes(slidingMinutesToExpire), System.Web.Caching.CacheItemPriority.NotRemovable, null);
        }
    }

Answer 2

No, Viewstate is coupled tightly with the use of the browser as an HTTP client.

For webservices, you have two choices: let the client track the state of the conversation, or let the server track it.

• Using the server session state, and passing a cookie (either HTTP cookie or some cookie-like parameter inside the SOAP envelope)

• requiring the client to track, retain, and possibly transmit to the server, the conversation state.

---

About Viewstate - it is state for the page as presented to the user, and as an implementation, it is tightly coupled to the browser. When the page is displayed, viewstate info is used to fill the page. Later, when a form on the page is posted, the relevant form data, some of which may have been preset with the viewstate magic, is then transmitted to the server. The server needs to validate the input from the client, despite the use of viewstate on the client side. You can see that viewstate coupled with some lightweight browser-side population logic is a way for the client to manage the state of the page the user is seeing, but the server cannot forgo validation for conversation state.

This approach can be taken in a web services application, but because there is no dependence on the browser or on a particular presentation (or any presentation at all), it is a do-it-yourself thing. The client application maintains and uses any conversational state in a way that is appropriate for the client.

On the other hand, Server-managed state means there is state information retained at the server for each "conversation" or "session". The client doesn't necessarily need to track the information, if the server is doing it. The client just presents a token (or cookie if you like) to the server and the server uses it as a lookup key into a state table. The server is primarily responsible for validating all state retained on behalf of the client.

Since you're using .NET, you might be interested to learn that Workflow can be used server-side to track the state of a webservices (WCF) based conversation. This approach maintains the WS network protocols - it does not stipulate any particular client technology or platform.

Answer 3

No, you can't use ViewState with web services. ViewState requires a hidden <input> field and an HTTP postback. Input fields aren't supported with web services.

Since ViewState requires encoding data and sending it to the client and back again, it's no more efficient than cookies, which are supported by web services since they're implemented at the protocol level, rather than as part of the HTML like ViewState.

Alternatively, you can use Session state, and keep the info on the server.

Answer 4

You can't use ViewState (or may be can after lot of unnecessary hard work:) in web service, but as alternative you can use session state. Session state is enabled for each WebMethod using EnableSession value:

[WebMethod(EnableSession=true)]
public int SessionHitCounter()
    {
    ...
    }

More info here at MSDN.

Answer 5

just create a array of cache objects within the session object :) the .dispose of the cache should release the session from memory as well :)