ADO.NET : Some internals uncovered Part 2

For the last 2 days, I thought of unleashing few of the hidden facts of Data Storage. It is true, that introduction of .NET framework without introducing Generic in first place is one of the biggest mistakes. Because of Non-Generic data structure a large amount of data is been unnecessarily boxed and unboxed without any reason as such. After Generics was introduced  with .NET 2.0, most of these classes which made you do type conversions is either been totally depreciated or few of them rarely used as is there for backward compatibility. But for every programmer, the most common class called DataTable still exists without any change. In this post we will try to see the actual implementation of DataTable as a whole, so that we could understand what is going on when we store data into it.

Introduction

DataTable is an application object that maps to a Database Table. It holds a collection of DataRows and DataColumns where DataRow represents the actual Data while the DataColumns holds Integration rules. Basically we all know the basics of DataTable and often use it for our regular work.

DataSet holds a list of DataTable, and DataRelation. DataTable as being said is the storage of Data in form of a Table with Row and Columns, the DataRelation holds the Relationship rules between two tables in a DataSet. Hence ADO.NET has been structured in such a way that you can have the flavour of entire database from your application end.

But, one thing that you must keep in mind, these objects are created way back in time of .NET 1.0 release or even before when there is no Generics or even the concept of State Machines. Generics allows you to pass type of an object during actual object creation and hence will allow you to create Type information based on the object which we create in real time, as a result it eliminates unnecessary runtime boxing and unboxing. Keeping this in mind, I thought I should check how these classes are made in Framework. Lets look each of them, one by one in this post and lets identify pros and cons.

WPF Tutorial

WPF, a.k.a Windows Presentation Foundation provides an unified model for producing high end graphical business application easily using normal XML syntax (known as XAML) which runs both in client and server leveraging the job to render output more relying on graphics devices rather than using GDI components.

If you are looking to learn WPF, its time to start on today. I have put all my articles on WPF in Codeproject, which you might find interesting and helpful.

Article Links : 

• WPF Tutorial : Beginning [^]
• WPF Tutorial : Layout-Panels-Containers & Layout Transformation [^]
• WPF Tutorial : Fun with Border & Brush [^]
• WPF Tutorial - TypeConverter & Markup Extension [^]
• WPF Tutorial - Dependency Property [^]
• WPF Tutorial - Concept Binding [^]
• WPF Tutorial - Styles, Triggers & Animation [^]  

I hope you would like those articles, comment on them and give feedback to them.

Thank you.

Internals of a Delegate

Strange Rules of Delegate

Well, at recent times, at least after the introduction of .NET framework 3.5 the use of Delegates in a program has increased quite a bit. Now almost every people in .NET language must at least somehow used delegates on their daily programming activities. It might be because of the fact that the use of delegates has been simplified so much with the introduction of lambda expressions in .NET framework 3.5 and also the flexibility to pass delegates over other libraries for decoupling and inversion of control in applications. Hence, we can say the way of writing code in .NET environment has been changed considerably in recent times.

Introduction

If you want the most simple and somewhat vague idea about delegates I would say a delegate is actually a reference to a method so that you might use the reference as you use your object reference in your code, you can send the method anywhere in your library or even pass to another assembly for its execution, so that when the delegate is called, the appropriate method body will get executed. Now, to know a more concrete and real life example, I must consider you to show a code :

public delegate int mydelegate(int x);
        public class A
        {
            public mydelegate YourMethod { get; set; }

            public void ExecuteMe(int param)
            {
                Console.WriteLine("Starting execution of Method");
                if (this.YourMethod != null)
                {
                    Console.WriteLine("Result from method : {0}", this.YourMethod(param));
                }
                Console.WriteLine("End of execution of Method");
            }
        }
        

        static void Main(string[] args)
        {

            //int x = 20;
            //int y = 50;

            A a1 = new A();

            a1.YourMethod = Program.CallMe;


            a1.ExecuteMe(20);

            Console.Read();
    }
     public static int CallMe(int x)
        {
            return x += 30;
        }

}

In the above code, I have explicitly declared a delegate and named it mydelegate. The name of the delegate will indicate that it is a type that can create reference to a method which can point to a method which have same signature as defined in it. Clearly If you quickly go through the code defined above, the property YourMethod can point to a signature which has same signature as declared to mydelegate. Hence, I can pass a method CallMe easily to Type A, so that when the object of A calls the delegate, it executes the method CallMe.

ADO.NET - Some Internals Uncovered

During the early phaze of your career, when you just have started learning about .NET technology, you might have came across the sentence "ADO.NET is a disconnected database architecture". Well, its true, but how? How can ADO is transformed to such an architecture which no other database architecture supports. Every other database programming supports only RecorsSet which you need to use to get Data from the database.  Did you ever thought of it ? If you don't, it is time to rethink of it now.

In this post, I will uncover few internals of ADO.NET architecture, and also refer to my favorite tool Reflector to see the code that is written inside the .NET classes. My focus in the post is only on the internals of the architecture, so if you  are new to ADO.NET, it would not be a good idea to read it over and confuse yourself more, rather read thorough Overview of ADO.NET and come back later.


Introduction

Well, In fact, I didn't ever thought of writing such a post. Strangely, while talking with Devs I found out people commenting that ADO.NET is a new way of accessing data missing out the point where ADO.NET differs with ADO. It is true, ADO.NET is disconnected. There are large performance gain of an application which releases the Connection after fetching data from the database. ADO.NET have inherent capability to release the database connection, after the so called DataSet / DataTable is filled with data which you might be looking for. There are few Adapters provided with .NET library which lets you Fill these DataSet or DataTable when you want and later you can use these cached data to your application.  Yes every line here is a fact. But internally there is still a Reader associated with every call. Let me detail the fact a little.


Details of Loading Data using Select Query

Say you invoke a Selection operation on the Database using Select Query. Lets jot down the steps what happens internally :

Ways of Throwing an Exception in C#

Exception handling is very common for everyone. Exceptions are runtime errors which might be caused by some operation illegal to the application. .NET provides a good Exception Model (even though Microsoft wants to change this model) using try/catch which lets us to deal with runtime exceptions from our code.

It is stated that, you write your code that might generate an exception inside try block, write the logic which handles the exception generated within the catch block ( like logging, notifying etc.), where catch block can overload. Also you should keep in mind, it is recommended to wrap your code in try / catch only if you think you can handle the exception, if you cannot, it is better to leave apart the exception and let the caller to handle this in their own code. Lets take an example :

public void FirstCall()
{
    try
    {

        this.SecondCall();
        Console.WriteLine("After Exception");
    }
    catch (Exception ex)
    {
        this.DumpException(ex);
    }
}

So in the above code the Try/catch block is introduced to implement the code with exception handling.  I am using DumpException which writes the exception to the Console.

Download Sample Code - 30 KB

Win32 Handle (HWND) & WPF Objects - A Note

Well, there is a common confusion for many who are working with WPF objects, is does it truly interoperable with Windows environment, or more precisely, does it act the same way as it does with normal Win32 objects?
The problem here comes with the fact that each WPF window has only one window handle (HWND) and each other controls are actually placed as content to the window and does not have any entry on Kernel table(no HWND) except of course Popup class in WPF. In this post I will try to cover the basis of HWND (for those of you who don't know) and later go on with what are the changes of it with WPF environment.

If you know what HWND is or how it works, please skip the next section.

Overview of Win32 HANDLE

Win32 Handle is very important for any Win32 applications. For every Win32 apps, Kernel maintains a Table which has entries to identify a memory address. A HANDLE is actually a DWORD (32 bit integer) which maps the memory address on the table. So if you get a HANDLE, you can easily locate the memory address it points to.  Each object that you have in Windows (like windows, buttons, mouse pointers, icon, menu, bitmap etc) has entries in the table and the object is traced using both internally by windows or by programs using those HANDLEs. Even though it is just an unsigned integer value, you should not edit the value, otherwise the HANDLE could not be used to point the object anymore.