LINQ To SQL Vs Entity Framework

Entity Framework is ORM(Object Relational Mapping) introduced by Microsoft. It proves very useful for new developers for it’s simplicity to query against conceptual schema and also has rich feature set. Many time the question has been asked in the interview to explain differences between Entity Framework and LINQ To SQL to the developers who has work experience in Entity Framework. I have made table of differences between these two technologies.

Parameter	LINQ To SQL	Entity Framework
DB Server	LINQ To SQL supports only Microsoft SQL Server 2000 and later version and even SQL Server 2000 has some limitations.	With Entity Framework you can plug any DB Server i.e. IBM DB2, Sybase SqlAnyWhere, Oracle, SQL Azure, and lot more.
Inheritance	In LINQ To SQL inheritance is difficult to apply. It supports Table Per Class Hierarchy(TPH).	In Entity Framework inheritance is simple to apply. It supports Table Per Class Hierarchy(TPH) and Table Per Type(TPT). It also provides limited support of Table Per Concrete Class(TPC).
Complex Type(Non scalar property of an entity type that does not have a key property) Support	LINQ To SQL does not support the creation of complex types.	Entity Framework support the creation of complex types.
Complexity	LINQ To SQL is easier to use.	Entity Framework is more complex compared to LINQ To SQL.
Model	LINQ To SQL provides one-to-one mapping of tables to classes.	Entity Framework enable decoupling DB Server(Database Schema) and Entity Representaion in terms of Model(Conceptual Schema). You can map one table to multiple entities or multiple table to one entity.
Development Time	LINQ To SQL is simple to learn and implement for Rapid Application Development, but it will not work in complex applications.	Entity Framework has more features which will take time to learn and implement, but it will work in complex applications.
Mapping Type	In LINQ To SQL each table is mapped to single class. Join table must be represented as a class. Also, complex types cannot be easily represented without creating separate table.	In Entity Framework a class can map to multiple tables.
File Type	It uses Database Markup Language(DBML) file that contains XML mappings of entities to tables.	Entity Framework uses four files EDMX, CSDL, SSDL and MSL. The later three are generated at runtime.
Query Capability	LINQ To SQL has DataContext object through which we can query the database.	With the Entity Framework, we can query database using LINQ To Entities through the ObjectContext object and ESQL(provides SQL like query language). In addition, Entity Framework has ObjectQuery class(used with Object Services for dynamically constructing queries at runtime) and EntityClient provider(runs query against conceptual model).
Performance	LINQ To SQL is slow for the first time run. After first run provides acceptable performance.	Entity Framework is also slow for the first run, but after first run provides slightly better performance compared to LINQ To SQL.
Future Enhancement	Microsoft intended to obsolete LINQ To SQL after the Entity Framework releases. So it will not receive any future enhancements.	Entity Framework has future enhacements.
Generate Database from Model	It has no capability to generate database from Model.	Entity Framework supports generation of database from Model.

Source: http://jinaldesai.net/linq-to-sql-vs-entity-framework/

Entity Framework vs LINQ To SQL vs ADO.Net

there are so many different data access technologies out there that it's not uncommon for me to get the question: Why should I use the Entity Framework?  Or what differentiates it from other options like just using ADO.Net SqlClient and friends, LINQ to SQL or something like nHibernate?  I like the second question better, because the truth is that different problems merit different solutions.  So here's just a quick take on my perspective about these:

Entity Framework vs. traditional ADO.Net

All of the standard ORM arguments apply here.  The highlights are that you can write code against the Entity Framework and the system will automatically produce objects for you as well as track changes on those objects and simplify the process of updating the database.  The EF can therefore replace a large chunk of code you would otherwise have to write and maintain yourself.  Further, because the mapping between your objects and your database is specified declaratively instead of in code, if you need to change your database schema, you can minimize the impact on the code you have to modify in your applications--so the system provides a level of abstraction which helps isolate the app from the database.  Finally, the queries and other operations you write into your code are specified in a syntax that is not specific to any particular database vendor--in ado.net prior to the EF, ado.net provided a common syntax for creating connections, executing queries and processing results, but there was no common language for the queries themselves; ado.net just passed a string from your program down to the provider without manipulating that string at all, and if you wanted to move an app from Oracle to SQL Server, you would have to change a number of the queries.  With the EF, the queries are written in LINQ or Entity SQL and then translated at runtime by the providers to the particular back-end query syntax for that database.

Entity Framework vs. LINQ to SQL

The first big difference between the Entity Framework and LINQ to SQL is that the EF has a full provider model which means that as providers come online (and there are several in beta now and many which have committed to release within 3 months of the EF RTM), you will be able to use the EF against not only SQL Server and SQL CE but also Oracle, DB2, Informix, MySQL, Postgres, etc.
Next there is the fact that LINQ to SQL provides very limited mapping capabilities.  For the most part L2S classes must be one-to-one with the database (with the exception of one form of inheritance where there is a single table for all of the entity types in a hierarchy and a discriminator column which indicates which type a particular row represents).  In the case of the EF, there is a client-side view engine which can transform queries and updates made to the conceptual model into equivalent operations against the database.  The mapping system will produce those views for a variety of transformations.
You can apply a variety of inheritance strategies: Assume you have an inheritance model with animal, dog:animal & cat:animal.  You can not only do what L2S does and create a single table with all the properties from animal, dog & cat plus a column that indicates if a particular row is just a generic animal or a dog or a cat, but you can also have 3 tables where each table has all of the properties of that particular type (the dog table has not only dog-specific columns but also all the same columns as animal), or 3 tables such that the dog and cat tables have only the key plus those properties specific to their type of animal and retrieving a dog object would involve a join between the animal table and the dog table.  And you can further combine these strategies so some parts of a hierarchy might live in one table and some parts in separate tables.
In addition you can do what we call "entity splitting" where a single type has properties which are drawn from two separate tables, and you can model complex types where there is a type which is nested within a larger entity and which doesn't have its own separate identity--it just groups some properties together.  The best example of this is something like address where the street, city, state and zip properties go together logically, but they don't have independent identity.  The address is only interesting as a set of properties that are part of a customer or whatever.  As you have noticed, for v1 you can't create complex types with the designer in the EF--you have to code them by hand in the XML files.

Entity Framework vs. nHibernate

Because nHibernate is a rather full-featured ORM, the distinguishing features between the EF and it are not as large.  In fact, it is certainly true that nHibernate is a more mature product and in many ways has more ORM features than the EF.  The big difference between the EF and nHibernate is around the Entity Data Model (EDM) and the long-term vision for the data platform we are building around it.  The EF was specifically structured to separate the process of mapping queries/shaping results from building objects and tracking changes.  This makes it easier to create a conceptual model which is how you want to think about your data and then reuse that conceptual model for a number of other services besides just building objects.  Long-term we are working to build EDM awareness into a variety of other Microsoft products so that if you have an Entity Data Model, you should be able to automatically create REST-oriented web services over that model (ADO.Net Data Services aka Astoria), write reports against that model (Reporting Services), synchronize data between a server and an offline client store where the data is moved atomically as entities even if those entities draw from multiple database tables on the server, create workflows from entity-aware building blocks, etc. etc.  Not only does this increase the value of the data model by allowing it to be reused for many parts of your overall solution, but it also allows us to invest more heavily in common tools which will streamline the development process, make developer learning apply to more scenarios, etc.  So the differentiator is not that the EF supports more flexible mapping than nHibernate or something like that, it's that the EF is not just an ORM--it's the first step in a much larger vision of an entity-aware data platform.