Entity Framework vs LINQ to SQL
Solution 1:
LINQ to SQL only supports 1 to 1 mapping of database tables, views, sprocs and functions available in Microsoft SQL Server. It's a great API to use for quick data access construction to relatively well designed SQL Server databases. LINQ2SQL was first released with C# 3.0 and .Net Framework 3.5.
LINQ to Entities (ADO.Net Entity Framework) is an ORM (Object Relational Mapper) API which allows for a broad definition of object domain models and their relationships to many different ADO.Net data providers. As such, you can mix and match a number of different database vendors, application servers or protocols to design an aggregated mash-up of objects which are constructed from a variety of tables, sources, services, etc. ADO.Net Framework was released with the .Net Framework 3.5 SP1.
This is a good introductory article on MSDN: Introducing LINQ to Relational Data
Solution 2:
I think the quick and dirty answer is that
- LINQ to SQL is the quick-and-easy way to do it. This means you will get going quicker, and deliver quicker if you are working on something smaller.
- Entity Framework is the all-out, no-holds-barred way to do it. This means you will take more time up-front, develop slower, and have more flexibility if you are working on something larger.
Solution 3:
Is LINQ to SQL Truly Dead? by Jonathan Allen for InfoQ.com
Matt Warren describes [LINQ to SQL] as something that "was never even supposed to exist." Essentially, it was just supposed to be stand-in to help them develop LINQ until the real ORM was ready.
...
The scale of Entity Framework caused it to miss the .NET 3.5/Visual Studio 2008 deadline. It was completed in time for the unfortunately named ".NET 3.5 Service Pack 1", which was more like a major release than a service pack.
...
Developers do not like [ADO.NET Entity Framework] because of the complexity.
...
as of .NET 4.0, LINQ to Entities will be the recommended data access solution for LINQ to relational scenarios.
Solution 4:
There are a number of obvious differences outlined in that article @lars posted, but short answer is:
- L2S is tightly coupled - object property to specific field of database or more correctly object mapping to a specific database schema
- L2S will only work with SQL Server (as far as I know)
- EF allows mapping a single class to multiple tables
- EF will handle M-M relationships
- EF will have ability to target any ADO.NET data provider
The original premise was L2S is for Rapid Development, and EF for more "enterprisey" n-tier applications, but that is selling L2S a little short.
Solution 5:
LINQ to SQL
- Homogeneous datasource: SQL Server
- Recommended for small projects only where data structure is well designed
- Mapping can be changed without recompilling with SqlMetal.exe
- .dbml (Database Markup Language)
- One-to-one mapping between tables and classes
- Supports TPH inheritance
- Doesn't support complex types
- Storage-first approach
- Database-centric view of a database
- Created by C# team
- Supported but not further improvements intended
Entity Framework
- Heterogeneus datasource: Support many data providers
- Recommended for all new projects except:
- small ones (LINQ to SQL)
- when data source is a flat file (ADO.NET)
- Mapping can be changed without recompilling when setting model and mapping files Metadata Artifact Process to Copy To Output Directory
- .edmx (Entity Data Model) which contains:
- SSDL (Storage Schema Definition Language)
- CSDL (Conceptual Schema Definition Language)
- MSL (Mapping Specification Language)
- One-to-one, one-to-many, many-to-one mappings between tables and classes
- Supports inheritence:
- TPH (Table Per Hierarchy)
- TPT (Table Per Type)
- TPC (Table Per Concrete Class)
- Supports complex types
- Code-first, Model-first, Storage-first approaches
- Application-centric view of a database
- Created by SQL Server team
- Future of Microsoft Data APIs
See also:
- LINQ To SQL Vs Entity Framework
- Difference between LINQ to SQL and Entity Framework
- Entity Framework vs LINQ TO SQL