Boosting Your .NET Application Performance - Performance, Scalability and Future Development (Page 3 of 7 )
As I said earlier, each choice you make in the architecture will affect one of the following:
or Future Development.
Here we will look at the most common choices you have to make in a typical ASP.NET application. I'll present you with some of the available options, cons and pros of each.
Note: You should develop an application bottom up. This means build the data tier layer first. You should always design all three layers before building the actual application.
Performance vs. Scalability vs. Future Development When deciding on your architecture, decide what your priority is going to be. If your application is time critical, then you might have to sacrifice its scalability and extendibility just because you need more procedural like class design, which will offer that.
If you want scalability then you might have to sacrifice performance, because the scalability comes from scaling out and scaling out means communicating through a slower medium such as a LAN. Extensibility is a good thing to have but what's the point if you won’t be updating the application in the future, but instead be rewriting the whole thing? Think about whether you need extensibility or not because it can affect performance due to having more round trips to the database and also due to the simple fact that the size of the application will be bigger.
Think about what you really need for the project you are doing not what other people are doing for their projects. Architecture is a topic that really doesn't have best practices so rather than going for architecture for all of your applications, think about different architecture for each of your applications.
Presentation Tier Issues The presentation layer must be well planned before building it. If this layer is badly designed, it could impact on the applications performance and future development paths. I'll explain why.
Firstly, let's start with performance. Remember how I said that the presentation layer 'uses' BLL to do any operations that need interaction with the data tier? No matter how well you've designed your BLL to reduce the round trips or unnecessary trips to the data tier, if the presentation layer code calls that method one or more times unnecessarily, you are still doing a round trip to the data tier. This impacts on your applications overall performance.
Performance is also affected by the different types of controls you decide to use. For example, using a DataGrid instead of a DataList or Repeater will make a noticeable performance difference. So, when do you use a DataGrid and when do you use others? We will discuss this in a minute.
Secondly, future development is also impacted upon if the presentation layer is badly designed. How? If you have repetitive HTML code in all pages of your website, what happens if you want to change a color of a table or something? Do you go to each page and change it? What would you do if your boss said "No, I don't like that... Change it back!"? You really need to implement a template system into your web pages, so when you make one change to your site design, it's propagated to all pages.
Although not related to performance and future development, the presentation layer has another role in ASP.NET applications – security. You have 4 security options in ASP.NET, and we will have a look at each option in detail shortly. Before that though, let's get back to the DataGrid, DataList and Repeater issue.
Data Grid, Data List, Repeater Knowing the differences between these controls is very important because they are very different controls made for different uses, but people tend to get them confused.
Performance wise, you must always use a Repeater wherever possible. It is the fastest control out of the three. Unfortunately, it is also very limited in what it can do. All a repeater can do is iterate through the data source and display its properties.
A data source can be a data object such as a DataReader or dataset, but it can also be your custom collection that implements the IEnumerable and/or the IEnumerator interface. This is very good for displaying read only items such as list of news headlines, a summary of recent articles, etc.
There are times when you want to be able to "select" a row. When the row is selected, you want different item templates to be displayed. This situation is when you use a data list. DataLists allow you to select a row and display data using different templates. This is very useful for items that might need some frequent modification such as a list of news headlines for administrators where you want administrators to be able to edit headlines, etc.
The DataGrid is an interesting control. I always use it when I have a dataset as my data source. Although it's really slow, it is very flexible. It's also capable of producing a professional looking list or grid automatically. It knows the database's schema. It knows the type of fields and displays them accordingly. But one of the best features it has is its ability to allow editing of the data without having us code any postback functions, etc.
I find it great for administrative sections as it is not used very often but offers the greatest flexibility and convenience. If you need the greatest performance possible, however, then don't use a DataGrid.