If you have designed n-Tier applicationss before, then you might know how tiring it is to create a data access layer – create a connection, create a command, run a query, close the connection -- It's all very repetitive. There is a Microsoft answer to your prayer. It's called a data application block.
Data application blocks are available for free at the MSDN site. They are a great way to reduce DAL code for your application that has SQL Server as its backend database. Instead of creating a connection class, command class and DataReader or dataset class, you can just pass a connection string and get a DataReader or DataSet object returned. Visit the MSDN site to learn more about them.
For my application I found that my DAL code qA reduced by more than 2 times, simply by using an application block. A good thing about this is that there is no noticeable performance hit.
Application blocks are excellent tools provided by Microsoft. There is another application called an exception management application block that allows you to manage and log exceptions easily. Apparently, there are a few more application blocks to be released by Microsoft in the future.
Data Tier Issues
For the data tier, I always use stored procedures. I strongly recommend that you also use stored procedures for absolutely everything you possibly can, because they are fast (because they are compiled and cached) and easier to modify in the future. For example, when you suddenly decide that you need to separate your customer table into 2 separate tables, you can do that just by modifying the relevant stored procedures. You don't need to touch your .NET code.
Tips and Tricks of OOP in ASP.Net
People say "ASP.Net is good because it's Object Orientated", but many times they don't really use the functionality of Object Orientation provided by ASP.Net. Here, I'll show you just one of the ways to use Object Orientation in ASP.Net.
Everyone knows that an ASPX page is inherited from the Page class, right? Well, by making a custom Page class that inherits the Page class and by making your ASPX pages inherit from that class, you can have custom methods or properties in every page. One great way to use this technique is for error logging.
If a page has an error, the OnError event is raised, and if you want to log that error to an event log then you can put some code in the OnError event of that page. But do you really want to put that error logging code in every single page? No. You can avoid this by adding the error logging code in your custom Page class. Then all you have to do is make all of your pages inherit from that page.
Even if you don't think you will need methods that need to be used in all pages, its good practice to create a custom Page class anyway, so that if you need it for some reason in the future it's all ready and waiting to go.
One of the things I did with my custom page class was to make a page tracking application. I've made a custom page class, and overridden the OnLoad event handler where I added my page tracking code. The only thing I have had to do to track pages is just inherit from this class instead of the Page class.
Stress Test
I can't stress enough on how important this is -- Always stress test your application using tools like the Microsoft Stress Tool (which are available for free), because you will find a bottleneck you haven't been able to find with just you and your colleagues testing the site.
Monitor the performance counters when you stress test and see what operation causes the graph to skyrocket, and also what causes it to stay high.
Naming Conventions
Try to use the recommended naming conventions in your application. Microsoft recommends following conventions:
- For public properties, use upper case for the first letter of the word. e.g. BorderColor.
- For private variables, use camelCase, e.g. borderColor.
Enumerators
Try to use enumerators whenever possible. That way you are making your code more readable and understandable by other developers. For example, don't do this:
switch ( articleCategory) {
case 1:
// do something Category PHP
break;
case 2:
// do something for Category .NET
break;
}
... instead, do this:
enum Categories
{
PHP =1,
DotNET=2
}
switch ( articleCategory) {
case Categories.PHP:
// do something Category PHP
break;
case Categories.DotNet:
// do something for Category .NET
break;
}
Caching
Always try to use caching for your application whenever possible. The performance boost from caching is enormous. This is because when a page is cached it's like retrieving a static HTML page from the server instead of a dynamic one.
Think about whether your site really needs content that is up to date every second. I usually find that people are scared of using cache because they are afraid that their content will be less dynamic. True – sometimes -- but most users don't mind content being delayed for 10 to 20 minutes. If you're running a content driven site, then new articles can wait 10 or 20 minutes before they are live.
In my opinion, every you really do need to display up to the second information, such as a stock price quote site, etc. If you think it's not practical to cache a whole site, then cache portions of it. You can cache user controls within the page. A good use of that would be caching your menus. Your menus shouldn't change that often. Also, if you're running an e-commerce site then cache your catalogue as a dataset. Play around with caching and I can assure you, you will be surprised at how much of a performance gain your can attain.
Comments