Ever wonder what all these new-fangled data-based technologies coming from Microsoft can do for you? Who can keep track of everything? There’s ADO.NET, LINQ to SQL, ASP.NET MVC, Entity Framework and OData, to name a few. Not to mention the code names and name changes: Oslo is now SQL Server Modeling; Gemini is now PowerPivot; ADO.NET Data Services is now WCF Data Services; and of course, my personal favorite, ADO Data Services v1.5 is now Data Services Update for .NET Framework 3.5 SP1. The list goes on and on.
ADO.NET provides consistent access to data sources such as Microsoft SQL Server, as well as data sources exposed through OLE DB and XML. Data-sharing consumer applications can use ADO.NET to connect to these data sources and retrieve, manipulate, and update data.
ADO.NET cleanly factors data access from data manipulation into discrete components that can be used separately or in tandem. ADO.NET includes .NET Framework data providers for connecting to a database, executing commands, and retrieving results. Those results are either processed directly, or placed in an ADO.NET DataSet object in order to be exposed to the user in an ad-hoc manner, combined with data from multiple sources, or remoted between tiers. The ADO.NET DataSet object can also be used independently of a .NET Framework data provider to manage data local to the application or sourced from XML.
LINQ to SQL is a component of .NET Framework version 3.5 that provides a run-time infrastructure for managing relational data as objects. In LINQ to SQL, the data model of a relational database is mapped to an object model expressed in the programming language of the developer. When the application runs, LINQ to SQL translates into SQL the language-integrated queries in the object model and sends them to the database for execution. When the database returns the results, LINQ to SQL translates them back to objects that you can work with in your own programming language.
The ASP.NET MVC Framework is a web application framework that implements the model-view-controller pattern. Based on ASP.NET, it allows software developers to build a Web application as a composition of three roles: Model, View and Controller. A model represents the state of a particular aspect of the application. Frequently, a model maps to a database table with the entries in the table representing the state of the application. A controller handles interactions and updates the model to reflect a change in state of the application, and then passes information to the view. A view accepts necessary information from the controller and renders a user interface to display that.
The ADO.NET Entity Framework is designed to enable developers to create data access applications by programming against a conceptual application model instead of programming directly against a relational storage schema. The goal is to decrease the amount of code and maintenance required for data-oriented applications.
The Open Data Protocol (OData) is a web protocol for querying and updating data. OData applies web technologies such as HTTP, Atom Publishing Protocol (AtomPub) and JSON to provide access to information from a variety of applications, services, and stores. OData emerged organically based on the experiences implementing AtomPub clients and servers in a variety of products over the past several years. OData is being used to expose and access information from a variety of sources, including but not limited to relational databases, file systems, content management systems, and traditional web sites. Microsoft has released OData under the Open Specification Promise (OSP) to allow anyone to freely interoperate with OData implementations.
At last week’s MIX 10 Conference, Shayam Pather provides an excellent, step-by-step, hands-on demo starting out with the most basic .NET data access and ending with the new darling debutante, OData. Here is a link to it