Question

请问.net为什么抛弃了linq to sql? EF与linq to sql 相比较，前者有哪些优势？

Answer 1

说是抛弃也不太对，因为这部分被合并在Linq to Entity里面了。

ADO.Net Entity Framework 与Linq to SQL的比较和适用场景：
MSDN上最近发表了一篇Elisa Flasko著的文章，比较了LINQ to SQL与LINQ to Entities适用的场景:
Introducing LINQ to Relational Data
http://msdn2.microsoft.com/en-us/library/cc161164.aspx
作者指出，LINQ to SQL主要的应用场景是针对微软SQL Server数据库的快速开发，这些应用的对象模型与数据库中数据定义的结构间非常类似，几乎有一一对应的映射关系，这样你可以使用LINQ to SQL把一些数据表直接映射到.NET类，数据字段映射到的相应的.NET类的属性上。作者总结如下：
LINQ to SQL适用之场景
.想使用ORM方案，而且数据库数据定义与对象模型是1：1对应关系
. 想使用ORM方案，而且对象继承结构储存在单一数据表中（单表继承）
. 想使用原始CLR类，而不是使用生成的类或需要从某个基类继承而来，或者需要实现某个接口
. 想使用LINQ来编写查询
. 想使用ORM，但需要性能非常好，可以通过存储过程和编译的查询来优化性能
LINQ to Entities主要的应用场景针对的是需要非常灵活和更复杂的映射的场景，特别是在企业应用方面，而且需要访问其他的数据库系统。在这些场景中，数据表的结构与对象模型也许差别很大，而且应用开发人员往往并不拥有生成或修改数据库数据定义的权利。
LINQ to Entities适用之场景 :

.想要开发针对微软SQL Server或其他数据库系统的应用
. 想要定义领域模型，并以之为持久层的基础
. 想要使用ORM方案，对象也许与数据库数据定义有1:1对应关系，也许结构迥异
. 想要使用支持单表继承和其他储存方案（每类一表，每具体类一表）的ORM方案
. 想使用LINQ来编写查询，并且查询可以在不同数据库系统下工作
. 想使用ORM，但需要性能非常好，可以通过存储过程和编译的查询来优化性能

Answer 2

请问.net为什么抛弃了linq to sql? EF与linq to sql 相比较，前者有哪些优势？
LINQ to SQL主要的应用场景是针对微软SQL Server数据库的快速开发，这些应用的对象模型与数据库中数据定义的结构间非常类似，几乎有一一对应的映射关系，这样你可以使用LINQ to SQL把一些数据表直接映射到.NET类，数据字段映射到的相应的.NET类的属性上。