Data-centric applications have two perspective layers. They are the data model and the object model. While the data model defines the way data is defined and stored, the object model defines how the same data will be represented to the user in the presentation layer or how it is exposed to the other layers of the application. The data model of the application usually deals with the storage and retrieval of the application's data to and from the relational store.

The relational store is used for data persistence, consistency, concurrency, and security. It contains the application's data and typically comprises a set of tables, views, functions, procedures, and relationships. You typically use T-SQL to query against the relational store, which returns result sets that contain columns and rows of data.

However, the data returned doesn't necessarily match the application's object-oriented programming model. Usually, we don't use the data returned in the same form in which it is returned from the relational store. We write the necessary code to transform the data returned from the relational store into business objects in the data access layer of the application. Similarly, you need to write code to transform your application's business objects into a form that can be persisted into your relational store. But, what if the schema of the underlying relational store changes?

Here's exactly where an ORM fits in. The figure given next shows how objects in an application can be mapped to the relational store by using a mapping layer. This mapping layer is provided by the ORM. An ORM is a method of representing the relational tables as entities in the object world. ORMs came onto the market to provide you with a framework using which you can connect your applications to the underlying database without having to write much code. Most importantly, you can use ORMs to connect to any database, increase development productivity, ensure database independence, and database portability.

To bridge this apparent mismatch between the data and the object models, ORM tools have evolved. They are used to reduce the code required to transform your application's business objects into a form that can be persisted into the relational store and vice-versa.

Microsoft first released its ORM by the name of LINQ to SQL, which shipped with .NET Framework 3.5 and Visual Studio 2008. However, LINQ to SQL was restricted to working with SQL Server databases only. Entity Framework is an attempt by Microsoft to provide you with an extended ORM built on top of the ADO.NET provider model and enable you to connect to and work with any database.