With ADO .NET there are two ways of retrieving multiple rows from a database table:
1. Using SqlDataAdapter to generate DataSet or DataTable
2. Using SqlDataReader to provide a read-only, forward-only data stream
The choice between the two approaches is one between performance and functionality. DataReader gives better performance, while DataAdapter approach provides additional functionality and flexibility. Following is a list of points telling you when to use which approach.
Use DataSet with SqlDataAdapter when:
1. You require a disconnected, memory-resident cache of data
2. You want to update some or all of the retrieved rows and use batch update facilities of the DataAdapter
3. You want to bind the data with a control that requires a data source that supports IList
Good-to-know points about SqlDataAdapter:
1. Fill method of SqlDataAdapter opens and closes the database connection for you. So you don't need to do connection management.
2. However, that means, if you require the connection to be open after the Fill Method, open the connection yourself before calling the Fill method, thus avoiding unnecessary close-open of the connection.
Use SqlDataReader when:
1. You are dealing with large volumes of data that is too much for maintaining in a single cache.
2. You want to simply read the data and present to the user (read-only data)
3. You want to bind the data with a control that requires a data source that implements IEnumerable
Good-to-know points about SqlDataReader:
1. Remember to call Close on SqlDataReader as soon as possible, since the connection to the database remains open as long as the data reader is active.
2. The database connection can be closed implicitly by passing the CommandBehavior.CloseConnection value to the ExecuteReader method - it ensures that the connection is closes when the data reader is closed.
3. Use typed accessor methods (GetInt32, GetString etc.) if the column's data type is know while reading data from the reader. This reduces the amount of type conversion required, improving performance.
4. If you want to stop pulling data from the server to client, call Cancel method on SqlDataReader before calling Close method. Cancel method ensures that the data is discarded. Calling Close directly however, will make the reader pull all the data before closing the stream.
The main advantage of the SqlDataReader approach over the DataSet approach is that the former avoids the object creation overhead associated with a DataSet. Note that the DataSet object creation will result in creation of many other objects like DataTable, DataRow, DataColumn and the Collection objects used to hold all these sub-objects.
Sunday, April 29, 2007
Saturday, April 28, 2007
Exception Handling Best Practices
Anyone who has been a programmer in his life, knows about exceptions and also knows that there is no exception to having Exceptions in one's code! Fresh programmers however often overlook the importance of having exception management framework in their applications. A proper, well-defined exception handling framework along with a logging framework is absolutely essential for making sure that your program or application does not spring surprises on you later!
So, what are the best ways of handling Exceptions in the code? What should one do and what should one not do as regards Exceptions?
1. Catch Exceptions the right way
In C# or in Java, the way to handle exceptions is to put the code that could generate the exception into a try..catch..finally block. If there are multiple catch blocks, make sure that these are ordered from the most specific type to the most generic type. This ensures that the catch block for the most specific type of exception is considered first for any given exception, thus guaranteeing a specific treatment to that exception if required.
2. Catch Exceptions only if you know what to do with them!
Most of us, most of the times, blindly write the try..catch blocks, just because the IDE makes us do it. Because of that we end up having catch blocks as below:
catch(Exception exp){ throw exp;}
Now, the thing to note here is that you have not done anything really by catching that exception. It has just been rethrown from the catch block. If you find such lines in your code, the first thing you should be doing is simply removing those catch blocks. Instead, let these exceptions propagate further to the caller methods - which perhaps know better what to do with them.
Catch an exception only if:
a. You want to log that exception - The exception message and the stack trace when logged give a good picture to the developer as to what has gone wrong.
b. You want to write some clean-up code - In this case you can rethrow the same exception if no extra information is needed
c. You want to write some code to recover from the exception
d. You want to add some relevant information to the exception - This is particularly necessary in multi-tier applications or end-user applications where some nice user-friendly message has to be shown to the user. As an exception is propagated up the call-stack, often the information associated with it becomes less relevant. In such cases, wrap the actual exception in a custom, application specific exception. Remember to store the actual exception in the "InnerException" property of .NET Exception class (This is possible in Java too). This ensures that the actual exception is never lost and can always be retrieved if required.
3. Use Exceptions sparingly
Catching and Throwing of Exceptions is performance intensive. Never use exceptions to control the normal flow of operations in the code.
4. Use Custom Exceptions
As mentioned in point 2 d., one of things that one can do after catching an exception is to wrap it up in a more understandable exception with some extra information. This is where we need custom exception classes, exceptions that are specific to your application. In .NET, this can be done by extending the "ApplicationException" class. The entire hierarchy of the application exceptions can be bundled into one single assembly so that it can be referenced everywhere in your application.
A comprehensive article on Exception Management in .NET at http://msdn2.microsoft.com/en-us/library/ms954599.aspx
So, what are the best ways of handling Exceptions in the code? What should one do and what should one not do as regards Exceptions?
1. Catch Exceptions the right way
In C# or in Java, the way to handle exceptions is to put the code that could generate the exception into a try..catch..finally block. If there are multiple catch blocks, make sure that these are ordered from the most specific type to the most generic type. This ensures that the catch block for the most specific type of exception is considered first for any given exception, thus guaranteeing a specific treatment to that exception if required.
2. Catch Exceptions only if you know what to do with them!
Most of us, most of the times, blindly write the try..catch blocks, just because the IDE makes us do it. Because of that we end up having catch blocks as below:
catch(Exception exp){ throw exp;}
Now, the thing to note here is that you have not done anything really by catching that exception. It has just been rethrown from the catch block. If you find such lines in your code, the first thing you should be doing is simply removing those catch blocks. Instead, let these exceptions propagate further to the caller methods - which perhaps know better what to do with them.
Catch an exception only if:
a. You want to log that exception - The exception message and the stack trace when logged give a good picture to the developer as to what has gone wrong.
b. You want to write some clean-up code - In this case you can rethrow the same exception if no extra information is needed
c. You want to write some code to recover from the exception
d. You want to add some relevant information to the exception - This is particularly necessary in multi-tier applications or end-user applications where some nice user-friendly message has to be shown to the user. As an exception is propagated up the call-stack, often the information associated with it becomes less relevant. In such cases, wrap the actual exception in a custom, application specific exception. Remember to store the actual exception in the "InnerException" property of .NET Exception class (This is possible in Java too). This ensures that the actual exception is never lost and can always be retrieved if required.
3. Use Exceptions sparingly
Catching and Throwing of Exceptions is performance intensive. Never use exceptions to control the normal flow of operations in the code.
4. Use Custom Exceptions
As mentioned in point 2 d., one of things that one can do after catching an exception is to wrap it up in a more understandable exception with some extra information. This is where we need custom exception classes, exceptions that are specific to your application. In .NET, this can be done by extending the "ApplicationException" class. The entire hierarchy of the application exceptions can be bundled into one single assembly so that it can be referenced everywhere in your application.
A comprehensive article on Exception Management in .NET at http://msdn2.microsoft.com/en-us/library/ms954599.aspx
Friday, April 27, 2007
Simultaneous calls to server from UpdatePanel
The simplest way of Ajaxifying your ASP .NET web page using the ASP .NET Ajax library is to make use of its "UpdatePanel" control. It allows parts of your web pages to get refreshed, avoiding whole page reloads. This control causes asynchronous postbacks to the server. On receiving a response from the server, only the components inside the UpdatePanel are re-rendered. With the Ajax approach of making the calls to the server asynchronously, the user interface remains active even after a request to the server has been initiated. This means that the user can click on other active buttons on the page and initiate some more asynchronous calls (assuming those actions are also ajaxified).
Does this mean that I can place multiple UpdatePanels on my web page, let the user perform many actions simultaneously, resulting in many asynchronous calls to the server and different parts of the page getting refreshed as and when the corresponding Ajax call ends? Well - the answer to this question is NO and to understand why it is important to understand how an asynchronous postback is (or is not) different from a regular postback
The asynchronous postback made by UpdatePanel is exactly the same as a regular postback except for one important thing: the rendering. Asynchronous postbacks go through the same life cycles events as regular pages. Only at the render phase do things get different, since only the components inside the UpdatePanel are re-rendered instead of the whole page.
What this means for us is: Assume that there are two UpdatePanels on a web page, with one button each. The user clicks on Button 1 in the first UpdatePanel and the processing starts. Since the UI remains active after the first Ajax call, the user clicks on Button 2 in second UpdatePanel - assuming that both the calls will go through and he will get to see both the updates in some time. However, what will happen is that the second button click will invalidate the asynchronous postback initiated by the first button click. Effectively, only the final and the second button click will actually get processed, instead of both!
Note: While this is the story of the ASP .NET Ajax UpdatePanel - another interesting thing is the limit of 2 simultaneous connections to a server, a restriction put by most of the browsers today. This means that even with the crude simple Ajax way, it is possible to process only two requests simultaneously. All the other requests will be queued by the browser, until a free connection is available.
Does this mean that I can place multiple UpdatePanels on my web page, let the user perform many actions simultaneously, resulting in many asynchronous calls to the server and different parts of the page getting refreshed as and when the corresponding Ajax call ends? Well - the answer to this question is NO and to understand why it is important to understand how an asynchronous postback is (or is not) different from a regular postback
The asynchronous postback made by UpdatePanel is exactly the same as a regular postback except for one important thing: the rendering. Asynchronous postbacks go through the same life cycles events as regular pages. Only at the render phase do things get different, since only the components inside the UpdatePanel are re-rendered instead of the whole page.
What this means for us is: Assume that there are two UpdatePanels on a web page, with one button each. The user clicks on Button 1 in the first UpdatePanel and the processing starts. Since the UI remains active after the first Ajax call, the user clicks on Button 2 in second UpdatePanel - assuming that both the calls will go through and he will get to see both the updates in some time. However, what will happen is that the second button click will invalidate the asynchronous postback initiated by the first button click. Effectively, only the final and the second button click will actually get processed, instead of both!
Note: While this is the story of the ASP .NET Ajax UpdatePanel - another interesting thing is the limit of 2 simultaneous connections to a server, a restriction put by most of the browsers today. This means that even with the crude simple Ajax way, it is possible to process only two requests simultaneously. All the other requests will be queued by the browser, until a free connection is available.
Sunday, April 22, 2007
New version of Visual Studio - code named "Orcas"
The successor of Visual Studio 2005, code named "Orcas" (named after an island - this knowledge is courtesy Wikipedia) had its Beta 1 release on April 19, 2007. This new Visual Studio version is Vista compatible and promises a lot of new features and enhancements and bug fixes (ahem!) as compared to Visual Studio 2005.
I am of course yet to try it out, but some of the features that caught my attention:
1. Support for WPF, WCF and a host of other .NET 3.0 technologies
2. Full integration with Visual Studio Tools for Office (VSTO)
3. Support for LINQ (Language Integrated Query)
4. Integrated support for ASP .NET Ajax Extensions
One sure thing to check out in the coming days for all the Microsoft Developers out there!
I am of course yet to try it out, but some of the features that caught my attention:
1. Support for WPF, WCF and a host of other .NET 3.0 technologies
2. Full integration with Visual Studio Tools for Office (VSTO)
3. Support for LINQ (Language Integrated Query)
4. Integrated support for ASP .NET Ajax Extensions
One sure thing to check out in the coming days for all the Microsoft Developers out there!
Thursday, April 05, 2007
Binding ASP .NET 2.0 GridView to a complex object using ObjectDataSource
The ObjectDataSource provided with ASP .NET 2.0 allows a GridView component to be bound a list of user defined objects. The columns in the gridview could be defined as "BoundFields", binding the column to a particular property of the user defined object.
However, this works fine, as long as the object is flat. In the current project that I am working on, we had a class structure as given below:
class ShoppingCartItem
{
int requestedQuantity;
ProductInfo product;
}
class ProductInfo
{
string productName;
string brandName;
}
We wanted to show the Product Name, Brand Name and Requested Quantity of each product in the Shopping Cart of the user in a tabular format using the GridView control. We were using the ObjectDataSource and binding the GridView with a list of ShoppingCartItem instances. Now, the problem was that the product name and brand name were not directly accessible from the ShoppingCartItem class. Instead they were properties inside the ProductInfo class, that was a part of the ShoppingCartItem class.
Solutions:
1. This particular problem could have been solved by using the TemplateField and the DataBinder.eval approach, but that meant changing a lot of things in the page.
2. Instead, a clean, quick and yet a very simple solution to this problem was to add wrapper methods inside the ShoppingCartItem class to get the product name and the brand name from the ProductInfo class. We could easily bind the column of the GridView to these wrapper methods inside the ShoppingCartItem class.
However, this works fine, as long as the object is flat. In the current project that I am working on, we had a class structure as given below:
class ShoppingCartItem
{
int requestedQuantity;
ProductInfo product;
}
class ProductInfo
{
string productName;
string brandName;
}
We wanted to show the Product Name, Brand Name and Requested Quantity of each product in the Shopping Cart of the user in a tabular format using the GridView control. We were using the ObjectDataSource and binding the GridView with a list of ShoppingCartItem instances. Now, the problem was that the product name and brand name were not directly accessible from the ShoppingCartItem class. Instead they were properties inside the ProductInfo class, that was a part of the ShoppingCartItem class.
Solutions:
1. This particular problem could have been solved by using the TemplateField and the DataBinder.eval approach, but that meant changing a lot of things in the page.
2. Instead, a clean, quick and yet a very simple solution to this problem was to add wrapper methods inside the ShoppingCartItem class to get the product name and the brand name from the ProductInfo class. We could easily bind the column of the GridView to these wrapper methods inside the ShoppingCartItem class.
Subscribe to:
Posts (Atom)
