Web forms makes it really easy to create a simple website, but it is also really difficult to create 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 minimize 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 minimize 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 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.
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.[crp]