ObjectDataSource control works with in-memory collections. It defines properties, such as InsertMethod, DeleteMethod, UpdateMethod, and SelectMethod, which perform basic data storage and retrieval operations. Appropriate methods must be created and mapped to these properties to perform the required task. When one of these properties is used, the ObjectDataSource control actually creates the instance and invokes the appropriate method, and it is destroyed as soon as it completes its execution phase. ObjectDataSource is usually used in the business layer of your application, which assists you to directly bind to the data-bound controls on the presentation layer.

The SqlDataSource control allows you to perform standard data operations, such as insert, update, delete, and select on the data persisting in your relation database. The SqlDataSource control is not meant only for the SQL Server database, and can work with any managed ADO.NET provider, which means that you can use the SqlDataSource control with different relational data sources. The SqlDataSource control defines properties, such as InsertCommand, DeleteCommand, UpdateCommand, and SelectCommand for performing standard data operations, such as insert, delete, update, and select on the data. The command properties need appropriate queries to be set before using them. When a data control that connects to a SqlDataSource control is updated, the SqlDataSource control creates update parameters for all the columns even though few columns are updated. The control also supports caching capabilities, which assist in improving the performance of the application.

The SiteMapDataSource control allows you to bind the site map of your website. The site map can represent a hierarchical structure. The SiteMapDataSource control needs an appropriate root node to be specified in a given hierarchy. The SiteMapDataSource control contains properties that allow you to specify the node locations. Primarily, the SiteMapDataSource control is used for the purpose of data navigation, which means you cannot perform standard data operations, such as insert, update, delete, sorting, and paging of the data.

The XmlDataSource control is another kind of DataSourceControl. Basically, it represents the data that is in the form of XML. You can access the XML data from the XmlDataSource control by connecting the control to a XML file or XML data embedded as a string within the data source control. Caching in the XmlDataSource control is enabled by default for increasing the performance. You can perform standard data operations, such as insert, delete, update, and select, over the XML data that is represented by the XmlDataSource control. However, operations like sorting and paging are not supported by the XmlDataSource control. The control also provides support for applying XML transformations through an XML stylesheet.

LinqDataSource control is a new control that has been introduced in ASP.NET 3.5. It extends DataSourceControl and resides in the System.Web.UI.WebControls namespace. It provides a new approach for binding LINQ models to the web controls in your ASP.NET applications. The LinqDataSource control provides properties and events using which you can perform operations such as selecting, filtering, grouping, and ordering of a LINQ data source.

The LinqDataSource data control provides a flexible mechanism to build a data control with a wizard-based workflow. It allows you to perform CRUD operations on the data over a LINQ model with minimal need of writing SQL queries.

The syntax remains the same for whatever data source you use. There is no need to define the queries for the select, delete, update, and insert operations manually.

LINQ provides the concept of a unified data model; all you have to do is focus on your logic, because the LinqDataSource control automatically creates the necessary commands for your needs.

The following example of code shows the syntax of using the LinqDataSource control:

<asp:LinqDataSource ID="ldsPurchaseOrderDetails" runat="server" ContextTypeName=" AdventureWorksDataContext" TableName="PurchaseOrderDetails" Select="new (ProductID, UnitPrice, StockedQty)">
</asp:LinqDataSource>

In the previous code snippet, ContextTypeName refers to the DataContext class. Note that a DataContext class is created automatically when you create a data model using the LINQ to SQL designer in Visual Studio 2013 IDE. The TableName property refers to a collection of the PurchaseOrderDetail type. The Select property extracts a new anonymous type containing the ProductID, UnitPrice, and StockedQty properties. In conjunction with the previous data source control, data controls such as DetailsView, GridView, or ListView can be used to bind the data. A simple syntax that represents the binding mechanism of a GridView's data source to the LinqDataSource control is as follows:

<asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="False"  DataSourceID="ldsPurchaseOrderDetails">
  <Columns>
    <asp:BoundField DataField="ProductID" HeaderText="ProductID" ReadOnly="True" SortExpression="ProductID" />
    <asp:BoundField DataField="UnitPrice" HeaderText="UnitPrice" ReadOnly="True" SortExpression="UnitPrice" />
    <asp:BoundField DataField="StockedQty" HeaderText="StockedQty" ReadOnly="True" SortExpression="StockedQty" />
  </Columns>
</asp:GridView>

The following example shows how the LinqDataSource control can be used for binding the in-memory objects to a DropDownList control:

<asp:LinqDataSource ID="LinqDataSource1" runat="server" ContextTypeName="Packt.Customer" TableName="FirstNames"></asp:LinqDataSource>
<asp:DropDownList DataSourceID="LinqDataSource1" runat="server" ID="DropDownList1"></asp:DropDownList>

In the Default.aspx.cs file, we will create a class named Customer. The class representation is as as follows:

public class Customer
  {
    List<string> names = new List<string>();
    public Customer()
    {
      names.Add("Joydip");
      names.Add("Sriram");
      names.Add("Sandeep");
      names.Add("Ramesh");
      names.Add("Sandy");
      names.Add("John");
    }
    public List<string> FirstNames { get { return names; } }
  }

The following figure illustrates the LINQ architecture:

Service operations are the methods that can be called over the data services, which have the same visibility as the entity sets. The IDataServiceConfiguration class supports the user-defined methods to be exposed over the data service. To do this, we need to set a WebGet attribute to this function and the access rule in the data service configuration of the data service.

The following code snippet illustrates a DataService class:

[System.ServiceModel.ServiceBehavior(IncludeExceptionDetailInFaults = true)]
public class GenericCollections : DataService<AddressSet>
{
  [WebGet]
  public IQueryable<Address> GetAddresssByCity(string City)
  {
    var addressquery = from addr in this.CurrentDataSource.Addresses
    where addr.City.Equals(City)
    select addr;
    return addressquery;
  }

  public static void InitializeService(IDataServiceConfiguration config)
  {
    config.UseVerboseErrors = true;
    config.SetEntitySetAccessRule("Addresses", EntitySetRights.AllRead);
    config.SetServiceOperationAccessRule("GetAddresssByCity", ServiceOperationRights.All);
  }
}

Here, we have used IQueryable<T> interface so that the method can return an IQueryable collection of the type T, where T is a class. The [WebGet] attribute allows the method to be accessible in the HTTP GET operations. Also, the class attribute [System.ServiceModel.ServiceBehavior(IncludeExceptionDetailInFaults = true)] on the GenericCollections class will show the stack trace just in case you encounter any exceptions at the time of execution.

The following code snippet shows how you can query the data exposed by the data service:

protected void Page_Load(object sender, EventArgs e)
{
  System.Data.Services.Client.DataServiceContext dataServiceContext = new DataServiceContext(new Uri("http://localhost:2490/GenericCollections.svc"));
  IEnumerable<Address> addresses =dataServiceContext.Execute<Address>(new Uri("http://localhost:2490/GenericCollections.svc/Addresses"));
  var addressquery =from address in addresses
    where address.City.StartsWith("S")
    select address;

  foreach (var address in addressquery)
  {
    Response.Write(string.Format("{0}<BR/>{1}<BR/>{2}<BR/><BR/>", address.AddressID, address.AddressLine,address.City));
  }
}

LINQ to SQL allows you to create object models that map to the tables in the relational database. The object-relational mapping implementation of LINQ to SQL handles the execution strategy of the SQL queries. A database markup language file, also known as .dbml file, is generated by the Visual Studio IDE when you drag-and-drop database tables from the solution explorer on the LINQ to SQL design surface. When each table is dragged onto the design surface, a class is created for each table. These classes, known as entity classes, are partial classes. They contain a set of partial methods that allow adding custom implementations. The objects to entity classes are known as entities. Associations are automatically created by the LINQ to SQL designer based on the underlying table relationships.

The entity relationships between primary and foreign keys are automatically represented as object relationships by the LINQ to SQL component. The mapping scheme offered by LINQ to SQL provides less housekeeping tasks when tables and columns are changed in the relational database. Only the mapping rules need to be updated without changing the code in your application.

The AdventureWorksDataContext class (created using the LINQ to SQL Designer in Visual Studio 2012) looks like the following code:

[System.Data.Linq.Mapping.DatabaseAttribute(Name="AdventureWorks")]
public partial class AdventureWorksDataContext : System.Data.Linq.DataContext