Pages

Thursday, August 8, 2013

Master Pages in ASP.NET

A professional web site will have a standardized look across all pages. For example, one popular layout type places a navigation menu on the left side of the page, a copyright on the bottom, and content in the middle. It can be difficult to maintain a standard look if you must always put the common pieces in place with every web form you build. In ASP.NET 2.0, master pages will make the job easier. You’ll only need to write the common pieces once - in the master page. A master page can serve as a template for one or more web forms. Each ASPX web form only needs to define the content unique to itself, and this content will plug into specified areas of the master page layout.

Marking Up Master Pages

To add a master page to a web project, right-click your web project in the Solution Explorer window, select Add New Item, and select the Master Page item type from the Add New Item dialog. The listing below shows a sample master page in source view.
<%@ Master Language="VB" CodeFile="otc.master.vb" Inherits="otc" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
            "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
  <title>Untitled Page</title>
  <link href="~/StyleSheet.css" rel="Stylesheet" type="text/css" />
</head>

<body>
  <form id="form1" runat="server">
    <asp:Menu ID="Menu1" runat="server" Orientation="Horizontal">
      <Items>
        <asp:MenuItem NavigateUrl="~/Default.aspx" Text="Home" Value="Home"/>
        <asp:MenuItem NavigateUrl="~/Experiments.aspx"
              Text="Experiments" Value="Experiments"/>
      </Items>   
    </asp:Menu>

    <div>
      <div id="main">
        <asp:ContentPlaceHolder ID="mainContent" runat="server" />
      </div>
      <div id="right">
        <asp:ContentPlaceHolder ID="sideContent" runat="server" />
      </div>
      <div id="footer">
        <asp:Literal ID="Footer" runat="server" Text="OdeToCode.com" />
      </div>
    </div>

  </form>
</body>
</html>

A master page looks very similar to an ASPX file, except a master page will have a .master file extension instead of a .aspx extension, and uses an @ Master directive instead of an @ Page directive at the top. Master pages will define the <html>, <head>, <body >, and <form>, tags. A new control, theContentPlaceHolder control also appears in our master page. You can have one or more ContentPlaceHolder controls in a master page. ContentPlaceHolder controls are where we want our ASPX web forms to place their content.
Just like any ASPX form, our master page can contain code in a <script> block, or in a code-behind file, and can respond to page lifecycle events. The MasterPage class (from the System.Web.UI namespace) derives from UserControl and will have all of the usual events: Init, Load, PreRender, etc. The following listing shows how we’ve added a Page_Load event handler to modify the color of the menu control on the page, and we’ve also added a property to allow setting and retrieving the text inside the footer.
Partial Class otc
  Inherits System.Web.UI.MasterPage

  ProtectedSub Page_Load(ByVal sender AsObject, _
                          ByVal e As System.EventArgs) _
                          HandlesMe.Load

    IfNot IsPostBack Then
        Menu1.BackColor = Drawing.Color.LemonChiffon
    EndIf

  EndSub


  PublicProperty FooterText() AsString
    Get
        Return Footer.Text
    EndGet
    Set(ByVal value AsString)
        Footer.Text = value
    EndSet
  EndProperty

EndClass

Plugging In Content

The ASPX web forms we use to put content into master pages are plain .aspx files, although with a few differences. When you add a new ASPX web form to a project you’ll have the option of associating the web form with a master page. Doing so will place a MasterPageFile attribute in the @ Page directive for the web form. The attribute points to the .master file you’ve selected (you can have multiple master pages in a web project). The source code below is for a default.aspx file using the otc.master master page we defined earlier.
<%@ Page Language="VB" MasterPageFile="~/otc.master"
    AutoEventWireup="false"
    CodeFile="Default.aspx.vb"
    Inherits="_Default" Title="Untitled Page" %>

<asp:Content ID="Content1" ContentPlaceHolderID="mainContent" runat="Server">
    <h1>mainContent</h1>
    Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Quisque auctor, dui a
    accumsan faucibus, erat dolor rhoncus massa, a hendrerit nulla purus eu dui. Morbi
    eget ligula. Proin sapien augue, sagittis vel, blandit sed, lobortis et, nulla.
    Nullam laoreet blandit erat. Ut egestas. Lorem ipsum dolor sit amet, consectetuer
    adipiscing elit. Pellentesque ut wisi at tellus placerat vestibulum. Aliquam at
    lacus non justo vulputate suscipit. Quisque mattis, arcu sed tempus fermentum, diam
    neque varius elit, vel eleifend nibh urna a pede.
</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="sideContent" runat="Server">
    <h4>sideContent</h4>
    Donec hendrerit. Aliquam at massa. Pellentesque sed justo. Donec interdum ipsum
    vitae nisl. Maecenas ac quam non lacus posuere convallis. Mauris nibh. Quisque mattis,
    arcu sed tempus fermentum, diam neque varius elit, vel
</asp:Content>

A web form associated with a master page is called a content page. A content page may only contain markup inside of Content controls. If you try to place any markup or controls outside of the Content controls, you’ll receive a compiler error: “Only Content controls are allowed directly in a content page that contains Content controls.”
Each Content control in a content page maps to exactly one of the ContentPlaceHolder controls in the Master Page. You do not need to define a content control for every ContentPlaceHolder control in the master. If a Content control doesn’t exist for a place holder, the master page will simply render the default content inside of the ContentPlaceHolder of the master page (we did not define any in this example).
The runtime examines the ID of each Content control and finds a ContentPlaceHolder with a matching ID. When the runtime finds the match it will take the markup and controls inside the Content control and insert them into the ContentPlaceHolder of the master page. Even though our Content controls in this example do not contain any server side controls, like GridView controls and Calendar controls, any ASP.NET control can appear inside the Content areas.
One benefit to working with master pages in the Visual Studio IDE is the built-in design support for master pages. The screen below shows our default.aspx form in a design time view. The Content controls are the only editable sections of the form. The master page markup displays in design view, but since we are editing default.aspx and not otc.master in the screen shot, the sections defined by the master page are un-editable and ghosted out. This gives designers and developers a clear idea of content versus the layout structure defined by the master page.
The second screen shot above shows our default.aspx web form in action. We’ve used a .css style sheet (shown below) to position the <div> tags on the page. The approach will give us a great deal of flexibility. We can make changes to the layout of the site simply by editing the CSS or master page, whichever makes the most sense for the change we need to make. In either case, we will never have to duplicate the <div>s on any of our web forms, the layout is controlled entirely in the master page.
body
{
    font-size: smaller;
}

#main
{
    float: left;
    width: 67%;
    background: #fff;
    border-right: 1px solid #000;
    margin-right: 15px;
    padding-bottom: 10px;
    padding-right: 10px;      
}

#footer
{
    clear: both;
    width: 100%;  
    text-align: center;
    font-size: 10px;
    padding: 3px;  
    border-top: 3px solid #333;
    background-color: #cccc99;
}

Programmatically Working With Master Pages

The MasterPage class derives from UserControl. The master page will inject itself as the top control in a page’s control hierarchy by clearing the page’s Controls array and adding itself to into the collection. Doing so includes all of the markup and controls defined inside the master page in the page's control tree. The master page can then walk the Content controls that existed in the web form and bring them back them into the control hierarchy in the appropriate locations. The master page injection happens after the PreInit event fires for a Page object, but before the Init event fires.
This ordering of events outlined above is important if you want to programmatically set the master page to use for a web form with the MasterPageFile property. This property must be set in the PreInit event (or earlier), like the code below. One the master page has injected itself into the control hierarchy it is too late to try to set a new master page for the web form. If you try to set the MasterPageFile property after the PreInit event fires, the runtime will throw an InvalidOperationException.
ProtectedSub Page_PreInit(ByVal sender AsObject, _
                           ByVal e As EventArgs) _
                           HandlesMe.PreInit
    ' we can select a different master page in the PreInit event
    Me.MasterPageFile = "~/otc.master"

EndSub

Another way to interact with a master page is through the Master property of a page object. Let’s say we need to get to the Footer property defined in our master page. There are two approaches to touching this property. The first is to use the Master property of the  System.Web.UI.Page class, which returns a MasterPage reference. In order to get to the Footer property, though, we would have to cast the reference to our derived master page type, like the following code.
CType(Master, otc).FooterText = "New Footer Text"

A second approach, if you know the exact master page file your page will be using at runtime, is to let the ASP.NET page parser generate a strongly typed Master property by adding an @ MasterType directive to your ASPX file, as shown below.
<%@ MasterType VirtualPath="~/otc.master"  %>

The MasterType directive will instruct the runtime to add a new Master property to code-generated file for the page. The new property will return a reference matching the MasterType. With a MasterType directive in place for our web form, we don't need a cast.  For more information on @ MasterType, see, “MasterType in ASP.NET 2.0“.
Master.FooterText = "Simple!"

URL Rebasing In Master Pages

The master page implementation outlined above has another consequence to watch for. Since the master page injects it's controls and markup into the page’s Controls array, any relative URLs in the master page markup may break. The browser will request the web form, not the master page, so all of the URLs will be relative to the web form. When the web form and master page are in different directories, relative URLs may point to the wrong location. To help alleviate relative URL problems, ASP.NET will rebase relative URLs for server-side controls in a master page. Rebasing will build the correct URL to the resource.
As an example, imagine we created our master page in the root directory of a web site, and we have an images subdirectory underneath the root. We might be tempted to add an image to our master page with the following markup.
<img src="images/tree.png" alt="1" />

The above URL will work as long as the web form using the master page is in the root directory. If we attach a web form in another subdiretory to the master page the image URL will break. One way to fix the broken URL is to turn the HTML <img> tag into a server side control by adding runat=”server”. Server side controls have their URLs rebased. Notice the <head> tag in the master page has runat=”server” in place, this will rebase your style sheet links.
<img src="images/tree.png" runat="server" alt="2" />

The following markup demonstrates what will work, and not work from a master page.
<!-- this will break -->
<img src="images/tree.png" alt="1" />

<!-- this wil work -->
<!-- server side control will rebase itself -->
<img src="images/tree.png" runat="server" alt="2" />

<!-- this will work -->
<!-- rooted references will always work, but are fragile -->
<img src="/masterp/images/tree.png" alt="3" />

<!-- this will break -->
<!-- app relative (~) only works on a server side control -->
<img src="~/images/tree.png" alt="4" />

<!-- this will work -->
<img src="~/images/tree.png" runat="server" alt="5" />       

<!-- both of these will work -->
<!-- the second Image will rebase URL -->
<asp:Image ID="Image6" runat="server" ImageUrl="~/images/tree.png" AlternateText="6"  />  
<asp:Image ID="Image7" runat="server" ImageUrl="images/tree.png" AlternateText ="7" />

<div style="background-image: url('images/tree.png');"  >
  My background is relative, and broken<br /><br />
</div>

<div style="background-image: url('/masterp/images/tree.png');"  >
  My background works<br /><br />
</div>

<div style="background-image: url('images/tree.png');" runat="server" >
  My background is broken. URL rebasing doesn't work for embedded style, event
  with server side control. <br /><br />
</div>

Nested Master Pages

You can write a content page that is itself a master page, allowing an arbitrarily deep nesting of master pages. This technique can be useful when your application is broken into sub-applications that need to inherit a common branded look but still be able to define their own customized layout template within the brand. The following listing shows a master page that would serve as a content page for our first master page example.
<%@ Master Language="VB" MasterPageFile="~/otc.master"
    CodeFile="otcchild.master.vb" Inherits="otcchild" %>

<asp:Content ID="Content1" ContentPlaceHolderID="mainContent" runat="Server">
  <div>
    <asp:ContentPlaceHolder ID="main1" runat="server" />
  </div>
  <div>
    <asp:ContentPlaceHolder ID="main2" runat="server" />
  </div>
</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="sideContent" runat="Server">
  <asp:ContentPlaceHolder ID="side1" runat="server" />
</asp:Content>


Notice we must obey the rules for a content page in this master page, that is, we can only define content inside of Content controls. The ContentPlaceHolders inside of these controls can then be filled in with web forms addressing the IDs of the nested master page. A web form cannot reach the ContentPlaceHolders in the master page above it’s own master page.
<%@ Page Language="VB" MasterPageFile="~/nested/otcchild.master"
    AutoEventWireup="false" CodeFile="Default.aspx.vb"
    Inherits="_Default" title="Untitled Page" %>

<asp:Content ID="main1" ContentPlaceHolderID="main1" Runat="Server">
  <h4>Content1</h4>
</asp:Content>

<asp:Content ID="main2" ContentPlaceHolderID="main2" Runat="Server">
  <h4>Content2</h4>
</asp:Content>

<asp:Content ID="side1" ContentPlaceHolderID="side1" Runat="Server">
  <h4>Content3</h4>
</asp:Content>

Master Pages and Configuration

There are three ways to associate a web form with a master page. You can use the Master attribute in the @ Page directive, and you can write to the MasterPageFile property in the PreInit event or earlier. We’ve seen examples of both of these techniques. Any web form using the Master attribute of the @ Page directive or setting the MasterPageFile property programmatically will override the web.config settings.
We can also assign a default master page for all web forms in a site in our web.config file using the <pages> element. An example excerpt from web.config is shown below.
<configuration>
  <system.Web>
    <pages master="otc.master" />
  </system.Web>
</configuration>

Of Headers and Meta tags

The last topic we will address is the topic of header information for ASP.NET web forms using a master page. The master page must define <head>, meaning the master page will include the <title> tag, among others. Since the master page does not know the title of the content page that will plug in, it simply sets the title to “untitled”.
Since a content page cannot contain any markup outside of Content controls, there is no way for a content page to use a title tag, but there is now a Title attribute in the @ Page directive. There is also a Title property on the page itself.
For other elements that end up in the header, the Page class now exposes a Header property of type HtmlHead. You can use the HtmlHead reference to modify style sheet settings and add HtmlMeta objects as needed.

Conclusions

Master pages provide a key component to any web application, namely the ability to organize a consistent layout into reusable templates. These master page templates offer full designer support and programmatic interfaces to meet the demands of most applications.

C# 3.0 and LINQ

In my previous article (an Introduction to LINQ), I described LINQ as a language agnostic technology. LINQ can work in Visual Basic just as well as it can work in C#. However, both languages introduced new features to facilitate and enhance the LINQ experience. In this article, we want to investigate the new features of C# 3.0. While the C# designers put together many of these features with LINQ in mind, the features can also be used outside of query expressions to enhance other areas of code.

Extension methods

Extension methods allow us to create the illusion of new methods on an existing type - even if the existing type lives in an assembly outside of our control. For instance, the System.String class is compiled into the .NET framework as a sealed class. We can't inherit from the String class, and we can't change the String class and recompile the framework. In the past, we might package an assortment of commonly used string utility methods into a static class like the following.
// Extending string via static methods (pre C# 3.0)public static class StringUtils{
    
static public double ToDouble(string data)
    {
        
double result = double.Parse(data);
        
return result;
    }
}
// Usage:
string text = "43.35";double data = StringUtils.ToDouble(text);
With C# 3.0, we can make our ToDouble method appear as a member of the String class. When the first parameter of a method includes a this modifier, the method is an extension method. We must define extension methods inside a non-generic, static class, like the StringExtensions class shown below.
// extending String via extension methodspublic static class StringExtensions{
    
static public double ToDouble(this string data)
    {
        
double result = double.Parse(data);
        
return result;
    }

    
static public int ToInt32(this string data)
    {
        
int result = Int32.Parse(data);
        
return result;
    }
}
StringExtensions defines two extension methods. We can now invoke either method using instance method syntax. It appears as if the methods are members of System.String, and we don't need to use the name of the static class.
string text = "43.35";double data = text.ToDouble();
Despite appearances, extension methods are not members of the type they are extending. Technically, the ToDouble method we are using is still just a static method on another type, but the C# compiler can hide this fact. It is important to realize that extension methods have no special privileges with respect to member access of the target object. Our extension methods cannot access protected and private members of the target object.

Extension Method Resolution

An extension method is available to call on any object instance that is convertible to the type of the method's first parameter. For instance, the following extension method is available for any object that is convertible to IList.
public static class IListExtensions{
    
public static void Randomize<T>(this IList<T> input)
    {
        
if (input == null)
            
return;

        
for (int i = input.Count - 1; i > 0; i--)
        {
            
int n = rand.Next(i + 1);
            T temp = input[i];
            input[i] = input[n];
            input[n] = temp;
        }           
    }
 
    
static Random rand = new Random();
}
We can use the extension method with an array of strings, as an array implements the IList interface. Notice we need to check for null, as it is legal and possible for a program to invoke an extension method on a null object reference.
void RandomizeArray()
{
    
string[] cities = { "Boston""Los Angeles",
                        
"Seattle""London""Hyderabad" };
    cities.Randomize();

    
foreach (string city in cities)
    {
        
Console.WriteLine(city);
    }
}
An extension method cannot override or hide any instance methods. For instance, if we defined a ToString extension method, the method would never be invoked because every object already has a ToString method. The compiler will only bind a method call to an extension method when it cannot find an instance method with a usable signature.
An extension method is only available when you import the namespace containing the static class that defines the extension method (with a usingstatement). Although you can always invoke the extension method via the namespace qualified class name (Foo.StringExtensions.ToDouble()), there is no mechanism available to reach a single extension method using an instance syntax unless you import the method's namespace. Once you import the namespace, all extension methods defined inside will be in scope. For this reason you should be careful when designing namespaces to properly scope your extension methods (see the LINQ Framework Design Guidelines).

Extension Methods and LINQ

LINQ defines a large number of extension methods in the System.Linq namespace. These extension methods extend IEnumerable<T> and IQueryable<T> to implement the standard query operators, like Where, Select, OrderBy, and many more. For instance, when we include the System.Linq namespace, we can use the Where extension method to filter an enumerable collection of items.
private static void UseWhereExtensionMethod()
{
    
string[] cities = { "Boston""Los Angeles",
                        
"Seattle""London""Hyderabad" };

    
IEnumerable<string> filteredList =
        cities.Where(
delegate(string s) { return s.StartsWith("L"); });

    
// filteredList will include only London and Los Angeles}
The definition for Where would look like the following:
namespace System.Linq
{
    
public static class Enumerable    {
        
// ...
        public static IEnumerable<TSource> Where<TSource>(
                                
this IEnumerable<TSource> source,
                                
Func<TSource, bool> predicate)
        {
            
// ...        }
       
        
// ..    }
}
As you can see, the second parameter to Where is of type Func<TSource, bool>. This parameter is a predicate. A predicate is a function that the Where method can invoke to test each element. If the predicate returns true, the element is included in the result, otherwise the element is excluded. Just remember - different LINQ providers may implement the filtering using different strategies. For example, when using the LINQ to SQL provider with an IQueryable<T> data source, the provider analyzes the predicate to build a WHERE clause for the SQL command it sends to the database – but more on this later.
We built the predicate by constructing a delegate using an anonymous method. It turns out that little snippets of in-line code like this are quite useful when working with LINQ. So useful, in fact, that the C# designers gave us a new feature for constructing anonymous methods with an even more succinct syntax - lambda expressions.

Lambda Expressions

In the days of C# 1.0, we did not have anonymous methods. Even the simplest delegate required construction with a named method. Creating a named method seemed heavy-handed when you only needed a one-line event handler. Fortunately, C# 2.0 added anonymous methods. Anonymous methods were perfect for simple event handlers and expressions – like the predicate we constructed earlier. Anonymous methods also had the advantage of being nested inside the scope of another method, which allowed us to pack related logic into a single section of code and create lexical closures.
C# 3.0 has added the lambda expression. Lambda expressions are an even more compact syntax for defining anonymous functions (anonymous methods and lambda expressions are collectively referred to as anonymous functions). The following section of code filters a list of cities as we did before, but this time using a lambda expression.
string[] cities = { "Boston""Los Angeles",
                    
"Seattle""London""Hyderabad" };
IEnumerable<string> filteredList =
    cities.Where(s => s.StartsWith(
"L"));
The distinguishing feature in this code is the "goes to" operator (=>). The left hand side of the => operator defines the function signature, while the right hand side of the => operator defines the function body.
You'll notice that the lambda expression doesn't require a delegate keyword. The C# compiler automatically converts lambda expressions into a compatible delegate type or expression tree (more on expression trees later in the article). You'll also notice the function signature doesn't include any type information for the parameter named s. We are using an implicitly typed signature and letting the C# compiler figure out the type of the parameter based on the context. In this case, the C# compiler can deduce that s is of type string. We could also choose to type our parameter explicitly.
IEnumerable<string> filteredList =
    cities.Where((
string s) => s.StartsWith("L"));
Parentheses are required around the function signature when we use explicit typing, or when there are zero or more than one parameter. In other words, the parentheses are optional when we are using a single, implicitly typed parameter. An empty set of parentheses is required when there are no parameters for the expression.
The right hand side of a lambda may contain an expression or a statement block inside { and } delimiters. Our city filter above uses an expression. Here is the same filter using a statement block.
IEnumerable<string> filteredList =
    cities.Where(s => { 
string temp = s.ToLower();
                        
return temp.StartsWith("L");
                      });
Notice the statement block form allows us to use multiple statements and provide local variable declarations. We also need to include a return statement. Statement blocks are useful in more complex lambda expressions, but the general guideline is to keep lambda expressions short.

Invoking Lambdas

Once we assign a lambda to a delegate type, we can put the lambda to use. The framework class library includes two sets of generic delegates that can fit most scenarios. Consider the following code:
Func<intint> square = x => x * x;Func<intintint> mult = (x, y) => x * y;Action<int> print = x => Console.WriteLine(x);

print(square(mult(3, 5))); 
// displays 225;
The Func generic delegate comes in 5 versions. Func<TResult> encapsulates a method that takes no parameters and returns a value of type TResult. Our square delegate is of type Func<int, int> - a method that takes 1 parameter of type int and returns an int, while mult is of type Func<int, int, int> - a method that takes 2 parameters of type int and returns an int. The type of the return value is always specified as the last generic parameter. Func variations are defined that can encapsulate methods with up to 4 parameters (Func<T1, T2, T3, T4, TResult>).
Action delegates represent methods that do not return a value. Action<T> takes a single parameter of type T. We use an instance of Action<int> in the above code. There is also an Action (no parameters). Action<T1, T2> (2 parameters), Action<T1, T2, T3> (3 parameters), and Action<T1, T2, T3, T4> (4 parameters). We can put all these delegates to work with lambda expressions instead of defining our own custom delegate types.
Remember the definition of the Where extension method for IEnumerable<T>? We created a lambda expression for the parameter of type Func<TSource, bool>. The implementation of the Where clause for IEnumerable<T> executes the lambda expression via a delegate to filter the collection of in-memory objects.
What happens if we aren't operating on an in-memory collection? How could a lambda expression influence a SQL query sent to a database engine for execution? This is where IQueryable<T> and expression trees come into play.

Expression Trees

Let's add a twist to our last example.
Expression<Func<intint>> squareExpression =
                            x => x * x;
Expression<Func<intintint>> multExpression =
                            (x, y) => x * y;
Expression<Action<int>> printExpression =
                            x => 
Console.WriteLine(x);
Console.WriteLine(squareExpression);Console.WriteLine(multExpression);Console.WriteLine(printExpression);
Instead of assigning our lambdas to an Action or Func delegate type, we've assigned them to an Expression<TDelegate> type. This code prints out the following:
x => (x * x)
(x, y) => (x * y)
x => WriteLine(x)
It would appear that the output is echoing our code. This is because the C# compiler treats Expression<TDelegate> as a special case. Instead of compiling the lambda expression into intermediate language for execution, the C# compiler compiles the lambda expression into an expression tree.
Our code is now data that we can inspect and act on at runtime. If we look at what the C# compiler produces for the squareExpression with a tool like Reflector, we'd see something similar to the following.
ParameterExpression x;            Expression<Func<intint>> squareExpression = Expression.Lambda<Func<intint>>(
    
Expression.Multiply(x = Expression.Parameter(typeof(int), "x"), x),
    
new ParameterExpression[] { x });
If we wanted to invoke the expression, we'd first have to compile the expression:
Func<intint> square = squareExpression.Compile();
int y = 3;int ySquared = square(y);
Console.WriteLine(ySquared); // prints 9
However, the real power of an expression tree is not in dynamic compilation but in runtime inspection. Again, our code is now data – a tree of Expression nodes that we can inspect. In fact, the C# samples for Visual Studio 2008 include an expression tree visualize – a plugin for the Visual Studio debugger to view expression trees. The following is a screen shot of the visualizer for our squareExpression.
Imagine writing some code that walks through the tree and inspects the types, names, and parameters. In fact, this is exactly what technologies like LINQ to SQL do. LINQ to SQL inspects the expression tree and converts the expression tree into a SQL command.
LINQ to SQL classes implement an IQueryable<T> interface, and the System.Linq namespace adds all the standard query operators as extension methods for IQueryable<T>. Instead of taking delegates as parameters like the IEnumerable<T> Where method does, IQueryable<T> will take Expression<TDelegate> parameters. We are not passing code into IQueryable<T>, we are passing expression trees (code as data) for the LINQ provider to analyze.
With an understanding of lambda expressions, expression trees, and extension methods, we are finally able to tackle one of the beauties of LINQ in C# - the query expression.

Query expressions

Query expressions provide the "language integrated" experience of LINQ. Query expressions use syntax similar to SQL to describe a query.
string[] cities = { "Boston""Los Angeles",
                    
"Seattle""London""Hyderabad" };
IEnumerable<string> filteredCities =
    
from city in cities
    
where city.StartsWith("L") && city.Length < 15
    
orderby city
    
select city;
A query expression begins with a from clause and ends with a select or group clause. Other valid clauses for the middle of the expression include fromlet,wherejoin, and orderby. We'll delve into these clauses in a future article.
The C# compiler translates a query expression into method invocations. The where clause will translate into a call to a Where method, the orderby clause will translate into a call to an OrderBy method, and so on. These methods must be extension methods or instance methods on the type being queried, and each has a particular signature and return type. It is the implementation of the methods, not the compiler, that will determine how to execute the query at runtime. Our query expression above would transform into the following:
IEnumerable<string> filteredCities =
  cities.Where(c => c.StartsWith(
"L") && c.Length < 15)
        .OrderBy(c => c)
        .Select(c => c);               
Since we are using an IEnumerable<string>, these method calls are the extension methods for IEnumerable<T>. From our earlier discussion we know that the compiler assigns each lambda expression to a delegate for the extension methods to invoke on the in-memory collection. If we were working with an IQueryable<T> data source, compiler would be creating expressions trees for a LINQ provider to parse.
Most of the lambda expressions in this query are simple, like c => c, meaning in the OrderBy case that given a string parameter c, sort the result by the value of c (alphabetical). We could have also said orderby c.Length, which translates into the lambda expression c => c.Length, meaning given a parameter c, sort the items by the value of c's Length property.
It's important to reinforce the fact that the C# compiler is performing a translation of the query expression and looking for matching methods to invoke. This means the compiler will use the IEnumerable<T> or IQueryable<T> extension methods, when available. However, in our own classes we could add methods like Where or OrderBy to override the standard LINQ implementations (remember instance methods will always take preference over extension methods). We could also leave out the System.Linq namespace and write our own extension methods to replace the standard LINQ implementations completely. This extensibility in LINQ is a powerful feature.

Intermission

We've now covered all the C# features that make LINQ work. The compiler translates query expressions into method calls. These method calls are generally extension methods on the queried type. The extension method approach doesn't force the queried type to use a specific base class or implement a particular interface, and allows us to customize behavior for specific types. Sorting, filtering, and grouping logic in the query expression is passed into the method calls using lambda expressions. The compiler can convert lambda expressions into delegates, for the method to invoke, or expression trees, for the method to parse and analyze. Expression trees allow LINQ providers to transform the query into SQL, XPath, or some other native query language that works best for the data source.
There are other features in C# that aren't required for all this magic to work, but they do offer everyday conveniences. These features include type inference, anonymous types, object and collection initializes, and partial methods.

Implicit Typing and Var

C# 3.0 introduced the var keyword. We can use the new keyword to define implicitly typed local variables. Unlike the var keyword in JavaScript, the C# version does not introduce a weak, loose, or dynamically typed variable. The compiler will infer the type of the variable at compile time. The following code provides an example. 
var name = "Scott";var x = 3.0;var y = 2;var z = x * y;
// all lines print "True"Console.WriteLine(name is string);Console.WriteLine(x is double);Console.WriteLine(y is int);Console.WriteLine(z is double);
Each variable has a type that the compiler deduced using the variable's initializer. For example, the compiler sees the code assign the name variable an initial value of "Scott", so the compiler deduces that name is a string. We are not able to try change this type later. The following code is full of compiler errors – things you can't do with var.
// ERROR: implicitly typed local varaibles must be initializedvar i;
// ERROR: Implicitly-typed local variables cannot have multiple declarators   var j, k = 0;
// ERROR: Cannot assign <null> to an implicitly-typed local variablevar n = null;
// ERROR: Cannot assign lambda expression to an implicitly-typed local variablevar l = x => x + 1;
var number = "42";// ERROR: Cannot implicitly convert type 'string' to 'int'int x = number + 1;
Implicitly type variables must have an initializer, and the initializer must allow the compiler to infer the type of the variable. Thus, we can't assign null to an implicitly typed variable – the compiler can't determine the correct type – any reference type can accept the value null! Lambda expressions themselves are not associated with a specific type, we have to let the compiler know a delegate or expression type for lambdas. Finally, we can see that once the compiler has determined the type, we can't change or morph the type like we can in some dynamic languages. Thus the number variable declared in the above code will always and forever be strongly typed as a string.
For practical purposes, the var keyword is important in two scenarios. The first scenario is when we can use var to remove redundancy from our code. For instance, when constructing generic types, all the type information and angled brackets can clutter the code (Dictionary<int, string> d = new Dictionary<int, string>). Do we need to see the type information twice to understand the variable is a dictionarty of int and string?
While the first scenario is entirely a matter of style and personal preference, the second scenario requires the use of var. The scenario is when you don't know the name of the type you are consuming – in other words, you are using an anonymous type.

Anonymous types

Anonymous types are nameless class types. We can create an anonymous type using an object initializer, as shown in several examples below.
var employee = new { Name = "Scott", Department = "Engineering" };Console.WriteLine("{0}:{1}", employee.Name, employee.Department);

var processList =
     
from process in Process.GetProcesses()
     
orderby process.Threads.Count descending,
             process.ProcessName 
ascending     select new     {
         Name = process.ProcessName,
         ThreadCount = process.Threads.Count
     };
Console.WriteLine("Process List");foreach (var process in processList)
{
    
Console.WriteLine("{0,25} {1,4:D}", process.Name, process.ThreadCount);
}
The first example in the above code constructs an anonymous type to represent an employee. Between the curly braces, the object initializer lists a sequence of properties and their initial values. The compiler will use type inference to determine the types of these properties (both are strings in this case), then create an anonymous type derived from System.Object with the read-only properties Name and Department.
Notice we can use the anonymous type in a strongly typed fashion. In fact, once we've type employee. into the Visual Studio editor, an Intellisense window will show us the Name and Department properties of the object.
We cannot use this object in a strongly typed fashion outside of the local scope. In other words, if we needed to return the employee object from the current method, the method would have to specify a return type of object. If we wanted to pass the variable to another method, we'd have to pass the variable as an object reference. We can only use the var keyword for local variable declaration – var is not allowed as a return type, parameter type, or field type. Outside of the scope of the current method, we'd have to use reflection to retrieve the property values on the anonymously typed object (which is how anonymously typed objects work with data-binding features in .NET platforms).
Anonymous types are also useful in query expressions. In the second half of the code above, we create a report of running processes on the machine. Instead of the query expression returning a Process object, which has dozens of properties, we've projected a new anonymous type with two properties: the process name and the process thread count. These types of projections are useful when creating data transfer objects or restricting the amount of data coming back in a LINQ to SQL query.
The initializers we've used are not only or anonymous types. In fact, C# has added a number of shortcuts for constructing new objects.

Initializers

The following two classes use auto-implemented properties to describe themselves.
public class Employee{
    
public int ID { getset; }
    
public string Name { getset; }
    
public Address HomeAddress { getset; }
}
public class Address{
    
public string City { getset; }
    
public string Country { getset; }
}
Given those class definitions, we can use the object initializer syntax to construct new instances of the classes like so:
Address myAddress = new Address { City = "Hagerstown", Country = "USA" };

Employee employee = new Employee {
        ID = 1,
        Name = 
"Sami",
        HomeAddress = { City = 
"Sharpsburg", Country = "USA" }
    };
The initializer syntax allows us to set accessible properties and fields on an object during construction of the object. We can even nest an initializer inside an initializer, as we have done for the employee's Address property (notice the new keyword is optional, too). Closely related to the object initializer is thecollection initializer.
List<Employee> employees = new List<Employee>() {
    
new Employee { ID=1, Name="...", HomeAddress= { City="...", Country="..." }},
    
new Employee { ID=2, Name="...", HomeAddress= { City="...", Country="..." }},
    
new Employee { ID=3, Name="...", HomeAddress= { City="...", Country="..." }}
};

Partial methods

Our coverage of C# features for LINQ wouldn't be complete without talking about partial methods. Partial methods were introduced into the C# language at the same time as LINQ. Partial methods, like partial classes, are an extensibility method to work with designer generated code. The LINQ to SQL class designer uses partial methods like the following.
public partial class Account{
    
public Account()
    {
        OnCreated();
    }

    
partial void OnCreated();
}
The Account class is a partial class, meaning we can augment the class with additional methods, properties, and fields with our own partial definition. Partial classes have been around since 2.0.
The partial method OnCreated is defined in the above code. Partial methods are always private members of a class, and their return type must always be void. We have the option of providing an implementation for OnCreated in our own partial class definition. The implementation is optional, however. If we do not provide an implementation of OnCreated for the class, the compiler will remove the method declaration and all method calls to the partial method.
Providing an implementation is just defining a partial class with a partial method that carries an implementation for the method.
public partial class Account{
    
partial void OnCreated()
    {
        
Console.WriteLine("Account created...");
    }
}
Partial classes are an optimization for designer generated code that wants to provide some extensibility hooks. We can "catch" the OnCreated method if we need it for this class. If we do not provide an implementation, the compiler will remove all OnCreated method calls from the code and we won't pay a penalty for extensibility that we do not use.

Summary

In this article we've covered most of the new features introduced into C# for LINQ. Although lambda expressions, extension methods, anonymous types and the like were primarily introduced to facilitate LINQ, I hope you'll find some uses for these powerful features outside of query expressions.