Best practices - ASP.Net and C# (personal list)
1. Dispose and release all memory intensive objects explicitly (using ‘using’ or using ‘dispose’ in the finally block)
2. Reduce database calls and unnecessary processing.
Store all calculated values and other such small data in session or viewstate instead of querying them from the database or calculating them again and again.
If any processing requires multiple database calls, try to do the processing within a stored procedure to reduce database calls.
3. Reduce the size of objects - retrieve only the data you need WHEN you need it.
If you’re using datatables and datasets in .Net, remember to call .AcceptChanges() whenever you make some changes to them.
Otherwise, these objects typically maintain all previous versions of data within them too.
5. Avoid post backs unless you need something from the session or the DB
Nearly all the work done on the forms- enabling / disabling, selection / de-selection of checkboxes and rows on grids, launching Pop-Ups etc - can be done on the client side.
6. HTML controls are easier to use with JavaScript, especially in DataGrids
They simply make the assembly heavier and slower.
7. Use validator controls in preference to direct javascript and / or server side validations
In addition to saving time spent in writing and maintaining JavaScript (the controls will do it) and providing uniformity in validation and error message display, the validation control also works on both ends
8. Thumb-rule for persisting values in web apps
Viewstate for storing values on a PAGE (will only be available for that one page for that one session) between post-backs Session for storing values across pages for one SESSION Application for storing values across the application lifetime (between IIS-resets, the value will be available to all sessions and in all pages)
9. When assigning attributes (like ‘onClick’) to web controls in the page load, it needs to be done only when (!IsPostBack)
10. No need to declare the exception object in catch block (even for throws) if the object isn’t needed.
11. Exceptions should not be used to control the flow
Exceptions should never be thrown during the normal course of working of the app since it’s basically an indication of a failure. A throw statement should only exist in a condition that should theoretically never arise.
12. Avoid excessive exception handling
Exception handling to be done only in interfaces to external systems and at uppermost layer. All other flow control can be done with status and message variables.
2. Reduce database calls and unnecessary processing.
Store all calculated values and other such small data in session or viewstate instead of querying them from the database or calculating them again and again.
If any processing requires multiple database calls, try to do the processing within a stored procedure to reduce database calls.
3. Reduce the size of objects - retrieve only the data you need WHEN you need it.
If you’re using datatables and datasets in .Net, remember to call .AcceptChanges() whenever you make some changes to them.
Otherwise, these objects typically maintain all previous versions of data within them too.
5. Avoid post backs unless you need something from the session or the DB
Nearly all the work done on the forms- enabling / disabling, selection / de-selection of checkboxes and rows on grids, launching Pop-Ups etc - can be done on the client side.
6. HTML controls are easier to use with JavaScript, especially in DataGrids
They simply make the assembly heavier and slower.
7. Use validator controls in preference to direct javascript and / or server side validations
In addition to saving time spent in writing and maintaining JavaScript (the controls will do it) and providing uniformity in validation and error message display, the validation control also works on both ends
8. Thumb-rule for persisting values in web apps
Viewstate for storing values on a PAGE (will only be available for that one page for that one session) between post-backs Session for storing values across pages for one SESSION Application for storing values across the application lifetime (between IIS-resets, the value will be available to all sessions and in all pages)
9. When assigning attributes (like ‘onClick’) to web controls in the page load, it needs to be done only when (!IsPostBack)
10. No need to declare the exception object in catch block (even for throws) if the object isn’t needed.
11. Exceptions should not be used to control the flow
Exceptions should never be thrown during the normal course of working of the app since it’s basically an indication of a failure. A throw statement should only exist in a condition that should theoretically never arise.
12. Avoid excessive exception handling
Exception handling to be done only in interfaces to external systems and at uppermost layer. All other flow control can be done with status and message variables.
Comments
Post a Comment