Things you need to know when programming in ASP.NET Web Forms

John Avis by | January 21, 2015 | ASP.NET Web Forms Web Development Web Development

Web forms makes it really easy to create a simple website, but it is also really difficult to crate a complicated website. These are some of the things you will need to know sooner or later.
Web forms makes it really easy to create a simple website, but it is also really difficult to crate a complicated website. These are some of the things you will need to know sooner or later.

Dynamic user controls

If you ever want to read the state or value of a control on post back, then a dynamic control must exist before you attempt to read the data. Unless you want to start getting data yourself from Request.Post, of course.

So on post back, usually in the Page_Init event, you should re-add any dynamic controls again.

The ASP.NET page life cycle

You need to be familiar with the ASP.NET page life cycle. You should know at least at what point any control's state is recreated from ViewState, when a control's value is populated on post back, and when control events fire, plus what Page events you need to use to do tasks before and/or after these happen.

You should also know what order events fire, between master pages, pages and user controls. You also need to know that some events play "catch up".

For more information see https://msdn.microsoft.com/en-us/library/ms178472.aspx.

Update Panels: friend or foe?

Update Panels have a bad reputation but they do have a lot going for them: they are part of the framework, and they make it possible to do complex AJAX operations with no client side code.

There are a few important points to keep in mind when working with Update Panels.

1. You should minimise the amount of markup and controls within an update panel as it will all have to be transferred to the client each post back.

If you are changing one control based on an event of another control, you don't need to put both controls in an Update Panel. You can put only the control that is affected, and make the other control a trigger for it.

2. You should minimise the amount of ViewState as it has to be transmitted to and from the server each post back.

3. If you change any control on the page on a partial post back, that control must be within an Update Panel and that Update Panel must get updated.

You should usually set all of your Update Panels UpdateMode property to "Conditional", which means that not all UpdatePanels update on a partial post back. With that setting, by default only the affected Update Panel will update but you can use the Update method of any other panel that also needs updating due to a change within. If you do use the Update method, you need to also do this on the affected Update Panel as it will no longer update automatically.

4. On partial post back all of your Page events will fire, just like any other post back.

Repeaters

Repeaters are very useful for many different purposes but when you combine Repeaters with Update Panels it can get complicated.

You generally need to register any control events that you need to be triggers for Update Panels in your code behind. You can do this in the repeater's ItemDataBound event or just iterate through the Repeater Item collection in Page_Render or wherever appropriate.

For more information see http://stackoverflow.com/a/15258052.

Linq to SQL

Linq to SQL makes it easy to handle related tables in your database, but you need to be aware of "Lazy Loading".

Lazy Loading means data is accessed only when needed.

As an example of what can go wrong, if your query returns 100 rows and then for each row you request the value from a related table, you will be performing 101 database queries. With some additional settings, you can do this in a single query instead.

For more information see https://msdn.microsoft.com/en-us/library/bb386920(v=vs.110).aspx.

ViewState

Everyone already knows that ViewState can be bad and cause performance issues with your website. By default it is turned on and it's quite easy to have kilobytes of ViewState on a page.

There are solutions to store ViewState on the server instead but the real solution is to turn off ViewState in your Master Page and then only turn it on for specific controls that need it.

Do you really need for ViewState to record your database-sourced DropDownList? You may be better caching the DropDownList values on the server and then re-adding them on each post back in the Page_Init event.


You might also want to read my Things you need to know when programming for the web post for more general web lessons.

Related Posts

Computers & Internet Web Development Website Hosting

500 Internal Server Error after migrating from IIS 7.5 to IIS 10

by John Avis | November 4, 2019

As support ends for Microsoft Windows Server 2008 I have recently gone through migrating some websites to a new server running Windows Server 2016 and IIS 10 but some of the websites did not work.


Jquery/Javascript Web Development

tagInput: A simple jQuery plugin for tag entry using Bootstrap 4

by John Avis | October 15, 2019

For a website project I needed a way to enter multiple tags. I just wanted something simple that I could easily modify to suit my own needs, so I wrote my own.


ASP.NET Web Forms Web Development

ASP.NET bug with RadioButton GroupName in Repeater

by John Avis | September 1, 2019

I rediscovered a bug in ASP.NET that affects RadioButtons inside repeaters. Here is my solution to the problem.

Comments

There are no comments yet. Be the first to leave a comment!

Leave a Comment

Tags

About me

...random postings about web development and programming, Internet, computers, electronics and automotive topics.

Subscribe

Get the latest posts delivered to your inbox.