We're about to start rebuilding one of our ASP.NET projects and I would like to try developing it without viestate turned on (disabled in web.config).
I know about the upsides and downsides of viewstate and generally speaking what it keeps track of in comparison to control state, however I would like to know:
What are the principle development process differences? Ie how differently do you structure your Page_Load etc?
Is there any functionality in the standard ASP.NET controls that really will just not work without viewstate turned on?
Also, are there any detailed articles on the workflow differences between working with and without VS?
If you are that against viewstate - why not try using the MVC framework? It may be an easier adjustment.
Most controls like TextBoxes and DropDownLists will function perfectly well without viewstate.
I don't know of any development process issues, other than any controls or properties created or modified through code will not persist without viewstate, so you would have to recreate/modify them on a postback.
I have some very big pages with large viewstates. I did an experiment to disable viewstate for the entire project, and found (at first) no noticeable loss of functionality. Then a few little issues came up in testing, so we reinstated it. But our 300 page web app was probably 99% functional without viewstate. The issues we had were centred around datagrids - paging mainly, and dynamically created controls and other things modified by code behind, and thus not persisted without viewstate.
This is a very good article on Viewstate:
http://msdn.microsoft.com/en-us/library/ms972976.aspx
I disable viewstate on my projects. I use scatter/gather methods to populate and get values from the aspx pages to/from my data access objects. It is a lot cleaner and simpler than using viewstate.
Related
When creating dynamic controls based on a data source of arbitrary and changing size, what is the official way to track exactly how many controls need to be rebuilt into the page's control collection after a Postback operation (i.e. on the server side during the ASP.NET page event lifecycle) specifically the point at which dynamic controls are supposed to be rebuilt? Where is the arity stored for retrieval and reconstruction usage?
By "official" I mean the Microsoft way of doing it. There exist hacks like Session storage, etc but I want to know the bonafide or at least Microsoft-recommended way. I've been unable to find a documentation page stating this information. Usually code samples work with a set of dynamic controls of known numbers. It's as if doing otherwise would be tougher.
Update: I'm not inquiring about user controls or static expression of declarative controls, but instead about dynamically injecting controls completely from code-behind, whether they be mine, 3rd-party or built-in ASP.NET controls.
This greatly depends on the problem at hand, and the type of controls you're recreating. Are they all simple text boxes or various different complex custom user controls. the main thing here is: if you want your dynamic control to regain state after a post-back, you have to re-create it in the Init phase of a page life-cycle.
Anyway. There's nothing like a Microsoft way or Microsoft recommended way basically. When you're dynamically adding several simple controls of the same type a hidden field with a count would do the trick, but when you have several complex controls other ways would have to be used. You could still hidden fields and save control's full type strings in them (ie. System.Web.UI.WebControls.TextBox) and re-instantiate them. But think of an even more complex example of putting various controls on different parts in the page... And initializing them to a specific state. That would be a bit more challenging. Hence no Microsoft way... The recommended way is to recreate in Init phase. And that's it.
Everything can be solved, but sometimes one took a wrong direction in the UI and things could be done easier using a different approach.
Additional explanation
This state-full technique of ViewState that Asp.net uses is considered the worse culprit with web developers in general. That's why Asp.net MVC developers think the new framework is bliss since its much more suited to the state-less HTTP protocol. Me being one of them. :D
I have a couple of pages that are bulky due to the viewstate. I have following question:
is there any tool that can track viewstate of individual control on page and tell me which control is taking maxm viewstate
also can i know which controls viewstate is not being used and disable it?
There are some Viewstate Utilities listed here http://blogs.msdn.com/rextang/archive/2007/05/25/2868250.aspx. I always store Viewstate in the database rather than send it back and forth over the internet. Example Code here http://www.componentworkshop.com/blog/2009/06/27/advanced-net-storing-viewstate-in-a-database
You can turn on trace on the page and that should show how much viewstate is used for each control.
I have no good answer to your second question, but one rule of thumb I use when i develop webforms is that i set EnableViewState=false immediately after I've created an Ascx.
That way I can turn it on when I actually need it and not wonder if my databound controls uses alot of viewstate.
I have read through the information in this question: Controls versus standard HTML but am still rather confused.
The situation was I was asked to do a web project where I made a wizard. When I was done with the project everyone asked why I had used an <asp:Wizard...>. I thought this was what was being asked for, but apparently not, so after this I was led to believe that server controls were just prototyping tools.
However, the next project I did my DB queries through C# code-behind and loaded the results via html. I was then asked why I had not used a gridview and a dataset.
Does anyone have a list of pros and cons why they would choose to use specific html controls over specific server controls and why? I guess I'm looking for a list... what server controls are okay to use and why?
EDIT:
I guess this question is open ended, so I'll clarify a few more specific questions...
Is it okay to use very simple controls such as asp:Label or do these just end up wasting space? It seems like it would be difficult to access html in the code behind otherwise.
Are there a few controls that should just never be used?
Does anyone have a good resource that will show me pros and cons of each control?
Server Controls Rely on ViewState, Restrict Flexibility
Server controls were powerful tools to introduce WinForms developers to web development. The main benefit that Server Controls provide is a sense of statefullness and an event-driven development model. However, the state of web development has been maturing since the introduction of WebForms and server controls, which as a whole are being challenged with an increasingly critical view.
The main issue with Server Controls is that they try to abstract the behavior of the web too much, and in doing so, rely on ViewState data and server resources to perform their magic. ViewState data, when used excessively, can severely bloat the size of your page, resulting in performance problems.
Now it is possible to opt out of ViewState, but by then it probably is better to simply resort to regular HTML controls.
With HTML controls, you have precise control over the content of the web page and you have greater flexibility in what behaviors you want on your web page. Server controls offer limited client-side flexibility and force a lot of work to be performed on the server that can easily be performed in the browser with a good JavaScript framework.
Is it okay to use very simple controls such as asp:Label or do these
just end up wasting space? It seems
like it would be difficult to access
html in the code behind otherwise.
If you need to access the control in server side code, use a server control. If not, don't.
Are there a few controls that should just never be used?
Not in my (mid level) experience. The Wizard control, once you know how to use it, works as advertised (imagine coding all the features yourself, then do the math). I've used it and it resulted in a smooth and functional multi-page sign up form with intermediate saving of data.
Does anyone have a good resource that will show me pros and cons of
each control?
I do not, but I'd recommend using the right control for the right situation. Study the differences between a Repeater and a GridView, for example, and use the best choice for your needs.
There of course are alternatives. For one, MVC is gaining momentum. Personally I have not yet committed to learning it. As far as interactive forms and AJAX goes, many .NET devs opt to use JQuery for any validation and any AJAX (UpdatePanels being easy to use and horribly inefficient), with JSON as the transport mechanism to the server side.
I'm working on replacing an existing web grid in an ASP.NET web application, with a new implementation. The existing grid is powerful, but not flexible enough. It also brings with it all kind of frameworks we don't like to have on our web pages.
While looking into existing options I noticed I can break the available solutions into two main approaches. The older approach is represented best by the ASP.NET GridView. This is a classic ASP.NET control that generates the needed HTML on the server, based on a given set of data. The newer approach is depending on client side rendering, mainly with jQuery. A good example would be jqGrid. Only the data is sent to the client (Usually with JSON or XML)
In the GridView case, if I want an AJAX behavior, I would have to implement it with something like an update panel.
Is there a definitive choice I should make?
Is there a good chance of achieving the same snappy behavior I get with jqGrid (even with many records), with server side rendered controls?
Is there some hybrid implementation incorporating both approaches?
There is no definitive choice you should make, but it's worth noting
that changing to client-side AJAX controls is a pretty big paradigm
shift that will require you to rethink how you do nearly everything
with the grid.
Going half-way (by using a server-side control such as GridView
in an UpdatePanel) will likely improve the user experience, since
the page will still be visible and responsive while it's updating. But
the UpdatePanel-style is still clunky compared to the new client-only
grids, because this technique sends all the page's form data when it posts back
(including all that ViewState in the GridView, if ViewState is turned
on). One brief note of caution: GridView is not compatible with
UpdatePanel when GridView.EnableSortingAndPagingCallbacks is set to true.
I haven't used any of they hybrid implementations (such as Coolite's Ext wrappers for .NET), but they are out there. There was at least one good SO discussion about this topic and the different grids available here.
I am also evaluating jgGrid vs. Gridview. I am just interested in the performance and efficiency of the grid. Even though jqGrid has a bit learning curve, I can invest some time in learning if it can provide great improvement in performance when compared to gridview. Can any expert throw more light on this topic?. Thank you very much.
On my journey into the depths of custom ASP.NET control development I am obviously getting my head around the ASP.NET PostBack model and how it affects control development.
I understand that controls have no "lifetime" in ASP.NET, and therefore must be re-initialized on each and every page load. We overcome this by persisting the objects values/parameters to the ViewState.
Many articles I read therefore suggest not using PostBack since this can add considerable overhead to the Page. I am not looking for how to disable it, I know that.
What I am looking for is:
What alternatives to we have to using the PostBack model to initialize controls?
I know we could use the QueryString, but that seems awfully messy, and obviously unreliable.
Ideally you could give me an overview of the architecture/design of a different approach and the pro's/con's of it..
Many thanks ^_^
Well, Session State is a server-side solution, with its own pile of cruft to deal with if you want to avoid ViewState altogether. Really though, using ViewState in a custom control is all fine and good - just be picky about what you store - only store deltas from the declared control state, don't store anything you're going to get on postback anyway (e.g. from a DB call), etc.
You have to store the values somewhere, so you are limited to the query string and hidden form fields. If you relate that to HTTP, basically it's either GET or POST parameters.
I suppose you could use cookies, but that would be really messy.
Store your object state in the session context: this will shift the burden of keeping state from the client to the server, which may be acceptable for small-scale intranet apps. For sites on the capital-I Internet, this won't work;
AJAX-enable your control: in this case, only state changes need to be posted back. Picking the right framework is key here; see http://www.asp.net/ajax/ajaxcontroltoolkit/samples/ for the official MS approach; many others are possible.
If you're truly looking for alternatives to the PostBack model altogether, then I would suggest researching the ASP.NET MVC Framework. I would love to kick WebForms to the curb and do all my stuff in MVC, but alas, legacy code is a tarbaby and rewriting is almost never the answer, so I plug onwards...
I think you still mis-understand controls somewhat. Controls only have the problem you describe when you add them to the page dynamically. If you declare your controls upfront in the aspx code then they build along with the page.