Performance TIPS

Hello friends,

Here are some performances TIPS, Please start using the same in your application.

Performance
The more the code is separated into different assemblies, the slower it Becomes. The reason for this slow performance is simple. It takes longer for a method in one assembly to call a method in another assembly than it would take if the method was in the same assembly. Some time is needed to refer to the other assembly, and read, find, and execute the required code.

Scalability
scalable means being able to handle an increased load in future.

Re-usability
If application code can be re-used within itself, or for some other external application, then not only do we save development and maintenance costs, but we also avoid code replication and make our code componented.

Loose-Coupling
UI interacted with business logic (BL) classes, which in turn called DAL methods. So if the DAL method breaks, the UI may not break as easily as if BL is directly interacted to Database, because we have made the layers loosely-coupled by bringing in a third layer (BL).

Plug and Play
Example: Application should work with MS SQL Server as well as with Oracle or any other database. So we need to make our DAL code capable of switching between databases. To achieve this, we create different DAL assemblies each having the code targeted to each database type, and we load a specific DAL assembly at runtime based on a key value in a config file. This means that our application is Plug and Play.

Communication between tiers via Data Transfer Objects (Data class which need some changes)
DTOs are simple and Flexible objects with no defined methods, and having only public members. They are like carriers of data to and from the layers. Some people use strongly typed datasets for the same purpose. The reason why we need DTOs is because passing business objects through layers is cumbersome as business objects are quite "heavy" and carry a lot of extra information with them, which is usually not needed outside the layers. So instead of passing business objects we create lightweight DTOs and make them serializable.

Lazy Loading
Using lazy loading pattern, we can defer the loading of all of the properties of an object until they are really needed. Let me explain with an example. In simple Customer data System application, consider a form that shows the list of all of the customers in a grid. Now, in this form, only the Customer ID, the first name and the last name are shown, along with an edit and delete button. The Customer address, email address, password and other fields are shown only
when someone edits an existing customer or adds a new one, a process which is done through another form. So if we want to load a list of Customer objects on this Customer List form, we don't need to fetch all the fields at once from the database. We only need to fetch the Customer ID, first name and last name fields to make our application more performance-efficient (by getting only the data required). And when we are on the Edit Customer form, we need to fetch all of the details. This can be done by having two methods in the DAL: one for a partial fetch and another for a complete fetch. But this approach is cumbersome, and we cannot always write two methods for each entity like this, So we follow the lazy loading design pattern, and use an enum like LoadStatus in our code, which can have several status.

Use Collection Object instead of List for data communication
instead of returning List we need to return Collectionfrom the DAL methods due to the fact that List should be used for internal use only, not in public APIs. Now our DAL is made in an API-like fashion. To make sure that our API is extendable, we need to use Collection as this is extendable, unlike Listwhere we cannot override any member. For example, we can override the SetItem protected method in Collection to get notified when the collection is changed (such as adding a new item and so on). Besides this, List has too much extra stuff that is useful for internal use only, and not as a return type to an API.

Call Database through Data Reader
Note the use of data readers for better performance. Data readers are read-only, one-way pointers to the database. Hence, they are much lighter and faster than data sets and data adapters (which in turn use data readers to map data). It is always better to use data readers for filling in custom entities so that we have a fine level of control over thedata access process, in addition to gaining the performance advantage of a data reader.

Paging Data
When you have to retrieve a large amount of data, it is a good idea to consider using data paging techniques to avoid scalability problems. Generally, follow the simple rule of not retrieving any more data than you require at any one time. For example, if you have to display 1,000 rows of data in a grid with 20 rows per page, implement data retrieval logic that retrieves 20 rows at a time. Data paging techniques help to reduce the size of data sets, and to avoid expensive and unnecessary heap allocations that are not reclaimed until the process is recycled.

Many Thanks,

Courtesy by Vivek Thakur from his book “ASP.NET 3.5 Application Architecture and Design”