Differed Execution (vs) Immediate execution in LINQ

Recently while understanding LINQ, many things unfurled from MSDN. The main theme of .NET is lazy binding (or) lazy loading. And it is evolving in all the ways within the .net Framework. I recollect in one of my previous posts about the mainly concentrated theme for every version that is released. I could be wrong from the insider perspective, but what I’ve observed is what I’ve written.

Anyhow, coming back to the main purpose of this post, which is all about the lazy loading and the point behind various execution mechanisms that are available within LINQ. Before I proceed further, one point is very certain that, choosing LINQ is costlier from the point of “Response Time” from DB to any connected system. This statement is true when compared the LINQ with any traditional mechanism of database connectivity.

Traditionally, every developer writes code with Connection object for connecting to the Data Store and then disposes the connection. This method can be by various objects that are provided within .net framework. One of the mechanism is that

• Use a connection object and DataAdapter
• Use a connection object along with Command and use either DataReader or DataSet

These mechanisms are pretty neat and straight, while connecting to the datastore. Where as they don’t provide the query mechanism to the developer against the returned results from the datastore. Ofcourse, you still could do the “Filter” method for the dataset or datatable object. This again doesn’t give the generic way to query from the data in the dataset / datatable.

LINQ, in this context provides a great flexibility for the developer to query against the data schema and provides a decent means of all kinds of DataBase querying techniques. In other words, I could say that LINQ gives the power of Database Querying to the C# developer. If your applications are developed using LINQ, you don’t need to have a DB developer. But you need the DB administrator to understand the health of the database and fine tune the queries used by LINQ. Hence, by choosing LINQ for your projects you are saving cost to the project owner. So, To LINQ or NOT to is upto you to decide. Let me not write more here about  LINQ and jump to the execution mechanisms within LINQ.

As titled in the post, there are 2 mechanisms for the execution of LINQ Results, I say it is about LINQ RESULTS. They are differed execution as well as Immediate execution. The main difference between these two are the lazy loading (or) JustInTime loading at the run time. To make simple this entire story, let me give you some code snippet, so that you would understand. For this am trying to query the Northwind Database.

Requirement:

Display all the employee names along with the product names and total of sold quantity

 

Solution 1 : In this solution am trying to use the LINQ as an Expression.

var empCounts = from eachEmpData in
 (from eachSale in
   (from eachEmp in nwDB.Employees
      join eachOrder in nwDB.Orders on eachEmp.EmployeeID equals eachOrder.EmployeeID
      join eachOrderDetails in nwDB.Order_Details on eachOrder.OrderID equals eachOrderDetails.OrderID
     join eachProduct in nwDB.Products on eachOrderDetails.ProductID equals eachProduct.ProductID
     where eachOrder.OrderDate > dtStart && eachOrder.OrderDate < dtEnd
                          select new
                          {
                              FirstName = eachEmp.FirstName,
                              LastName = eachEmp.LastName,
                              ProductName = eachProduct.ProductName,
                              OrderQuantity = eachOrderDetails.Quantity
                          }
                        )
    group eachSale by new { eachSale.FirstName, eachSale.LastName, eachSale.ProductName } into groupSales
                     select new
                     {
                         groupSales.Key.FirstName,
                         groupSales.Key.LastName,
                         groupSales.Key.ProductName,
                         Sold = groupSales.Sum(qty => qty.OrderQuantity)
                     })
                select eachEmpData;

// the below line binds the data from LINQ Expression

bsLINQData.DataSource = empCounts;

In this solution, you could see that I’ve written all the joins similar to that of the Database SQL joins. If you are familiar with all such queries, then it is very easy to write. But this kind of writing is also expensive. The alternative for such queries is the next solution.

Solution 2: In this solution am trying to use the same above LINQ as methods

var empCounts = nwDB.Orders
    .Where(eachOrder => eachOrder.OrderDate > dtStart && eachOrder.OrderDate < dtEnd)
                    .SelectMany(eachOrderDetails => eachOrderDetails.Order_Details)
                    .GroupBy(od => new { od.Product, od.Order.Employee })
                    .Select(od => new
                    {
                        FirstName = od.Key.Employee.FirstName,
                        LastName = od.Key.Employee.LastName,
                        ProductName = od.Key.Product.ProductName,
                        Sold = od.Sum(q => q.Quantity)
                    })
                    .OrderBy(s => s.Sold);

                // the below line binds the data from LINQ Expression
                bsLINQData.DataSource = empCounts;

In this solution, you find less coding and much usage of LINQ as methods. This kind of coding is much better than the previous solution. For the records, the above solution has taken about 3 milliseconds on my laptop where as the current solution took about 1 millisecond to query. See below for the stats and comparison.

Solution 3: The above two solutions are Differed execution, where as the current one is all about Immediate execution.

var empCounts = nwDB.Orders
    .Where(eachOrder => eachOrder.OrderDate > dtStart && eachOrder.OrderDate < dtEnd)
    .SelectMany(eachOrderDetails => eachOrderDetails.Order_Details)
    .GroupBy(od => new { od.Product, od.Order.Employee })
    .Select(od => new
    {
        FirstName = od.Key.Employee.FirstName,
        LastName = od.Key.Employee.LastName,
        ProductName = od.Key.Product.ProductName,
        Sold = od.Sum(q => q.Quantity)
    })
    .OrderBy(s => s.Sold).ToList();

// the below line binds the data from LINQ Expression
bsLINQData.DataSource = empCounts;

Here you have to observe the query ended with .ToList() and that is the trick of this query. When you see the statistics, it is very surprising that the time taken to query is very negligible when compared with binding the query results to the binding source. Which means that it is evident to say, LINQ doesn’t fetch the data when it is queried, but it fetches data when it is actually binded to any source.

Finally, the results when compared the above all the three solutions are as mentioned below

	Query	Bind
Expression	3	60
Methods	1	44
InList	35	9

 

Conclusion :

Solution 1 and Solution 2 are the examples for Differed Execution, where as the 3rd solution is an example for Immediate execution. Any comments?

C# 3.0 – What’s New : {Properties}-Part2

Property of the class can be considered as the mechanism of accessing the private variables of the class. In other words, properties act as wrappers to the private variables. Though, the new feature related to this is not so great from the point of technology, but highly meaningful from the developer point of view. In a large class code, having many fields and exposed as Properties, it is really difficult to remember the private fields association with the respective definition of properties. The new feature of Properties in C# 3.0 language specification says that the developer doesn’t require to define the private variables that are associated with the respective properties. During the good olden days, we are used to the following coding mechanism to declare the property via a private variable.

        // The private Variable declaration 
        string strEmpName; 

        // Property Declaration 
        public string EmployeeName 
        { 
            get { 
                // Returning the value from the private variable 
                return strEmpName; 
                } 
            set { 
                // Assigning the value to private Variable 
                strEmpName = value; 
                } 
        }

But hence forth, by using the C# 3.0 version, we doesn’t require to define as above but just as simple as mentioned below

        public string EmployeeName { get; set; }

How simple is this, by this method we doesn’t require to remember which is property and which is a private variable. But bottom line remains the same as of the old tradition, the only thing that every one has to remember is that, there is no need to declare a private variable and association of the same with the exposed property. Beneath the code, the compiler creates a private variable for each property that you define as such. To justify, use any reflector to understand the emitted IL code and the Assembly signature. You will surprise to note that a separate private variable is associated by the compiler.

Technorati Tags: C# v3.0

C# 3.0 – What’s New : {Implicit}-Part1

Recent development in my technical life is that, started working out with Orcas Beta 2. So, thought to blog about the latest happenings with C# language. The idea emerged to start a series of posts related to C# new features. This is the first of ever such kind of blogging specific to a topic.

C# 3.0 has many-a-new features. To start with, let me take a concept of Implicitly Typed Variables.

Implicitly Typed Variables

In the good old days, the developer has to worry about the type of the variable. Say for instance, whether to use long or double for a counter. Here all that we observe is that the language that is built upon is the type specific. Hence forth the developer is not required to define the type of the variable at the time of declaration, but it is the task of the compiler to decide what type of the object the variable is. All that the developer has to do is that, use the var keyword while declaring the variable, similar to that of JScript or Visual Basic style. Hey!!! Stop!!!!! don’t get confuse with the type of VAR variables declared at JScript or Visual basic.

Let’s first discuss the difference between VAR variables at JScript and VAR variables of C#

VAR JScript	VAR C#
This is of no type	The type of the variable is defined by the value declared and decided at the compile time
Technically have no type. Can consider of limited types, namely, string literal, numeric, boolean	Type agnostic, have specific predefined formats
Type conversion is coercion	Type casting is simple and handled by CLR
No mechanism for parsing	explicit functions for parsing to specific type

Now, let us see the difference between the language specific VAR of VisualBasic 6.0 and C# 3.0

VAR in VB (but not .NET)	VAR in C# 3.0
By definition, these are Variant	Type of the variable is defined at the compile time
Could be any allowed type from with in the known types of the language	Type is decided by the value associated with the variable
Largest among all the known data types	Size depends on the type of the value initialised

To summarize, the variables declared in C# 3.0 are type specific, thou used the key word VAR, during the declaration. Thus, we can conclude that the compiler is the responsible point to decide the type of the variable. Hence we can say with comfort that, the variables from C# 3.0 are Implicitly Typed variables.

Some examples as mentioned below.

            var vIntVal = 10; // This will be the System.Int32 type
            var vLongVal = 10000000000; // This will be the System.Int64 type
            var vDoubleVal = 10.0; // This will be the System.Double type
            var vFloatVal = 10.0f; // This will be the System.Single type
            float vFlVal = 10.0f; // Thou defined using float key word, but inherits from Struct System.Single 
            var vStrVal = "String Value ";  // This will be the System.String type

So, from the above declarations, it is pretty clear that the variable is defined by the value associated during the declaration. The type is not just limited to the kind of data types as explained above, but you can extend this to any type of the variable that you use while writing code for iterations, similar such as foreach. Below is the example for other known types.

            foreach (var vTable in ds.Tables) // Implicitly declared a variable of Data Table Type
            {
                foreach (var vRow in ((DataTable) vTable).Rows) // Implicit declaration of DataRow variable
                {

                }
            }

By using such, one can extend any extent. The limit is the imagination of the developer. What do you say?

Source:

1) http://cobdev.cob.isu.edu/psb/jscript/306.htm for JScript
2) http://www.1sayfa.com/1024/diger/vb/ch07.htm for Visual Basic 6.0 Datatypes

del.icio.us Tags: CSharp, 3.0, Code, Tips, Implicit

Designing Apps with .NET

A presentation that i recollected from my old mails. Can you talk about this?