Wednesday, May 16, 2007

Needs immense talent and patience

Does it look very familiar? Eiffel tower!

What is so special about this picture? Yes, the picture is model made by my cousin. He made that using the rib of the each coconut leaves. He has taken so much care about the details that it is amazing. His talent and patience is really of no par! It took some hundreds of such sticks, as he wanted each every piece of to be of the similar thickness. He has to stick each of this together… I don’t even seem to have patience to write the details… but I had enough patience to take a picture and put a quick notes!



Posted by Picasa

Tuesday, May 15, 2007

Dataset Vs Datareader - Again!

On reading my previous post on Dataset vs Datareader, one asked me, which one is better. I wanted to reply that. Then I realized there is enough to say that I can put a separate blog entry.

It is a difficult black and white recommendation to make.

Typically, when we design application, we try to achieve something called decoupled layers. Which means different application layer know nothing or minimal about each other. So, we always prefer a disconnected architecture. So, we always try to avoid tying up/carrying around the database connection across different layer. So, dataset kind of object sounds a favorable solution.

So let us think about two simple operations we do. Handling list of rows and handling single row.

One more drawback of Dataset other being bulky, it is not strongly typed. As an attempt to solve this Microsoft came up with strongly typed dataset. But it became too bulky. Then, it made sense to fill a simple object (object with simple getter setter) - Service layer or Business layer would fill in this object using datareader and pass around the Simple object to the "View" layer. Hey, this is when you handling single row. But when it comes to multiple rows, 90% of time we bind them against some.

When it comes to list of objects, intention can be a lot as well - could be that we want to list those records, or we want to enable multiple edit or batch update, or we want to keep the database kind of parent child relationship and transverse through them or we want to keep the database constraints and want to modify the dataset, or we want to integrate with legacy system where XML based object would make sense, or we want to load XML and build a familiar dataset object, or get XML from the underlying datalayer,... etc. Yes, it is really overwhelming to write them together what we can do with Dataset. But usual, worry about Dataset is it being bulk. But MS has something called DiffGram to alleviate the situation to reasonable extent.

So you make decision with design, performance and necessity in mind and try to strike a balance.

Saturday, May 05, 2007

Dataset vs Datareader

One of the most common coding we do is fetch bunch of rows from the database and view them or manipulate them. In such cases, we have 2 choice with us. Either to use DataReader or DataSet. How do you decide between these choice?

It needs to be quick!!! - DataReader is quick when it comes to just read the data and your intention is not modify the data but just view them

I need to modify or cache or transfer between multiple tiers!!! - DataSet gives us a flexible data structure to handle, it is disconnected, can be cached and you can modify them and save them.

The DataReader approach is generally quicker because it avoids the overhead that is associated with created a DataSet object. The overhead that is associated with a DataSet object includes creating DataSet subobject such as DataTable, DataRows and DataColumns. However, the DataReader provides less flexibility, and is less suited to situations where you have to cache data and pass the data to components in an application that has multiple tiers. The DataAdapter used to fill the DataSet uses a DataReader internally.

DataReader is recommended when the following conditions are true:
  • You need forward-only, read-only access to data and you want to access the data as quickly as possible, and you do not need to cache it.
  • You have a data container such as a business component that you can put the data in.

DataSet is recommended when the following conditions are true:

  • You have to cache or pass the data between layers.
  • You require an in-memory relational view of the data for XML or non-XMLmanipulation. like constraint, parent child, search,
  • You want to update some or all the retrieved rows, and you want to use the batchupdate facilities of the SqlDataAdapter class.
  • You have to bind data to a control type that the DataReader cannot be bound to. Many Windows Forms controls capable of data binding require a data source that implements the IList interface. The DataSet implements IList, but the DataReader implements IEnumerable. IEnumerable supports data binding to most Web Formcontrols but not to certain Windows Forms controls.
  • You have to access multiple sets of data at the same time, and you do not want to hold open server resources.

Friday, May 04, 2007

Script element "defer" attribute

Sometime is required write to a script something similar to below code snippet,
<HTML><HEAD><TITLE>Defer attribute Example</TITLE>
<script>
function HelloWorld(){
alert(document.getElementById('bodyDiv').innerText);
}
</script>
</HEAD>
<BODY>
<div id="bodyDiv">Hello world!!!</div>
<script>HelloWorld();</script>
</BODY>
</HTML>

Above code snippet works fine
You would see an alert on page load. Let us rewrite the above code slightly.
<HTML><HEAD><TITLE>Defer attribute Example</TITLE>
<script>
function HelloWorld(){
alert(document.getElementById('bodyDiv').innerText);
}
</script>
</HEAD>
<BODY>
<script>HelloWorld();</script>
<div id="bodyDiv">Hello world!!!</div>
</BODY>
</HTML>
Check the bold portion of the above code. I am calling a script that would try to access a DIV tag which placed below the javascript. This would mean, as you see, the DIV tag is not yet rendered and javascript refers to that object and you will get an error (Refer the image)

To avoid this, you can let IE know that this scripts need to executed only after the page is loaded. It can be done using "defer" attribute of <script> tag. If you set <script defer='defer' >HelloWorld();</script>, this script block will be executed only after the page load.

Typically, above simple scenario can be handled using onload event of body. But this is for any reason it could not be established, this is the workaround. Firefox does not seems to have such issue though.