What to keep in mind when desiging a new asp.net app?

E

eramgarden

Contributor
Joined
Mar 8, 2004
Messages
579
we have a desktop application done by a vendor. Not sure the language it's done with..i know it's not dotnet.

We're going to write an ASP.Net/VB.Net application using that desktop as our blue-print.

In general, what should we keep in mind when designing a dotnet web application from scratch? We're going to use VS2005/ASP.net2.0 and 3-tier. Should we use caching? do we need to keep machine.config in mind (change it to make performance better), I know we're gonna use stored procs, should we use sessions, what about security, garbage collection..

what should we absoultley keep in mind ..a rule of thump?
 
Here is some basic tips and tricks that I normally try to implement into whatever I build.

1- Centralize to make any updates to the code more easily.
2- If you use QueryString, make sure that you use the Parameters objects of the SqlCommand object. (Avoiding SQL-Injection)
3- Try not to use the garbage collection, it only slow down process and might have undesired effects.
4- Cache what you can cache. There is a lot of different caching method in .NET and you shall search which one is the best before actually implementing it.
5- Try to disable SessionState when you don't need it. This only make the loading more slower.
6- Put your connections strings in the Web.Config so that it's more easy to access them. (Accessible through System.Configuration.ConfigurationSettings.AppSettings("Something") )
7- Never make code write to Web.Config since it restart the web application and flush all sessions openned on it.
8- Always use stored procedures if possible. And use SqlParameter (can't stress more on that one). (and don't do any sqlexec in your MS SQL db either)
9- Have fun :P

I probably missed a lot of stuff but hey... there's other guy that will add a few on it.
 
Thanks for the good advice...

Last app i worked on was done by MCxxx and "MS gold partners" developers. A nightmare of timeouts , deadlocks and performance issues..

I know they used SPs and caching but not sure why it had so many issues..

any thoughts on how to keep the performance in mind?
 
Stored procedures are not a magic wand when it comes to performance - a badly written stored proc (i.e. returns too much data etc.) will still be a performance hit.
If the underlying DB is badly designed or tuned (too much / little indexing done, poor indexing, over / under normalised) will also impact performance.

Often deadlocks are a sign of a database design issue - better indexing, locking or knowing how to avoid (or at least limit) them through better SQL coding would help here.

Caching is only useful when the data is frequently accessed and changes rarely - caching should only be implemented if there is a proper performance monitoring / testing policy in place anyway - otherwise how do you know if it is working better or not?
 
Back
Top