在这一点上，LINQ to SQL或Entities更好？

Question

我有些晚参与并决定花一些空余时间学习LINQ。作为练习，我将在MVC 2中重写一个WebForms应用程序（这对我来说也是新的）。我成功地找到了一些关于LINQ的话题（Learning about LINQ、Beginners Guide to LINQ、Is LINQ to SQL Dead or Alive?），这引起了我关注实体和SQL的问题。

然而，这些话题都已经超过一年的时间了，我似乎找不到关于哪个ORM更可取的明确信息。Entities现在是否更或者少了LINQ to SQL 2.0？使用它是否仍然更困难？

是否有任何理由使用LINQ to SQL，还是直接使用Entities呢？我在目前的雇主处编写的应用程序寿命周期很长（约10年），因此我正在尝试选择最好的可用技术。

- orlon

---

现在 .Net 4.0 已经发布，两项技术都有很多变化，因此重新审视这个问题是很好的。 - DOK

重复：http://stackoverflow.com/questions/2874003/whats-the-best-object-relational-mapping-tool-for-net - Michael Maddox

Answer 1

在最近一篇关于扩展NerdDinner的文章中，Scott Hanselman谈到了这个问题。引用结尾的话：

“结论：.NET上有很多数据库访问选择。在旧代码或高度调整的代码中可能会遇到DataReaders，但没有理由不能将其隐藏在存储库中并仍然愉快地使用。LINQ to SQL很好、轻量级且快速，并在.NET 4中修复了几十个错误，但Entity Framework是他们未来的方向。此外，Entity Framework 4比EF 3.5好得多，因此我正在使用它进行任何“大于小”的项目，并且我没有遇到太多麻烦。”

“尽管我还没有太多机会去玩它，但EF4似乎已经赢得了许多专业人士的信任。”

- Tom

---

+1. EF4就像NHibernate一样简单，但不需要太多的设置工作。我很快就能够创建一个基本的数据库应用程序。比3.5上的EF更加清晰。但这取决于你想要什么；有些人喜欢在代码中看到DB抽象层，以便理解正在发生的事情。L2S仍然是一个很好的选择，并且稍后转换为EF也不难。 - drharris

好文章。我喜欢他如何给我们这些仍在使用DataReaders的古老过时的人一个不错的出路 - “高度调整”确实如此。 - orlon

@Orlon，我认为DataReaders的评论比其他评论更有意义，因为它让你对SQL语句拥有更加细粒度的控制。即使是最新和最棒的项目也可能在某个时候需要手动调整SQL。Stack Overflow 在一些地方使用DataReaders，在其他地方则使用LINQ to SQL。这就是所谓的漏斗抽象原则。 - Chad Levy

Answer 2

有没有理由使用LINQ to SQL，或者我应该直接使用Entities？

作为一位忠实的LinqToSql用户，我并不客观，但这是可以回答的问题。

对象关系映射技术是解决或减轻对象关系阻抗不匹配的尝试。它们是连接两个世界 - 对象世界和关系数据世界的桥梁。

似乎这些桥梁的开发人员通常都将其中一个视作自己的家。

LinqToSql是从对象方面的ORM。它由C#团队开发，可以让你使用对象来表示数据。在LinqToSql中，没有编译器不透明的字符串，所有查询都会根据映射被编译器检查。

EF是从数据方面的ORM。它由ADO团队开发，可以让你使用表示为对象的数据。在EF中，有大量不透明的字符串。

查询必须最终针对数据库运行，而编译器无法保证运行时可用的数据库与映射匹配（无论是哪种ORM都是如此）。由于数据世界的这个现实，数据团队不像C#团队那样重视编译器保证。

作为一名多年在TSQL后端工作、没有编译器保护的开发人员，我很高度珍视编译器提供给我的任何帮助。因此我支持C#团队。

例如，加载一个客户及其订单。

  //linq to sql.
DataLoadOptions load = new DataLoadOptions();
load.LoadWith<Customer>(c => c.Orders);  //<-- strong typed
myDataContext.LoadOptions = load;

IQueryable<Customer> query = myDataContext.Customers
  .Where(c => c.CustomerId == 1);

  //entity framework
IQueryable<Customer> query = myObjectContext.Customers
  .Include("Orders")  // <-- opaque string
  .Where(c => c.Customer.Id == 1);

- Amy B

---

耸肩。这个问题很容易解决，我无法想象为什么你会基于这个微小的问题做出决定。想要强类型的Include？你可以拥有它。现在你可以基于实质性问题做出决策了。 - Craig Stuntz

这不是一个完整的解决方案。那么Customer.Orders.Items怎么办？ - Amy B

此外，Include方法并不是唯一的情况 - 事实仍然是，在他们的库中，C#团队想要编译器验证而ADO团队则不想。 - Amy B

我并没有说这是一个完整的解决方案；我说这是一个微不足道的问题。而且我会反驳它在某种程度上普遍存在的观点。编写不使用魔术字符串的EF应用程序并不难，就像编写使用魔术字符串的L2S应用程序一样不难。最后，说ADO团队“不想要”这个显然是荒谬的。你认为谁拥有LINQ to SQL？ - Craig Stuntz

Answer 3

这篇文章与Hanselman的文章类似。它比较了DataReader（他们称之为“连接”数据访问），类型化的DataSet（“断开”的），LINQ to SQL和Entity Framework。对于所有方法，都提供了详细的代码示例，以及每种方法的优缺点。

- DOK

Answer 4

我在2009年初仔细研究了这两种技术，并听取了许多有关“LINQ-to-SQL即将死亡”的传言。最终，我仍然选择了LINQ-to-SQL而不是Entity Framework，因为我从未喜欢过使用ADO.NET，EF让我太过于紧密地绑定到数据库。

在我的开发项目中，我的历史一直是：

1. 构建模式
2. 构建与模式配合工作的数据库对象
3. 构建与数据库对象交互的数据层
4. 构建与数据层交互的业务层

对于EF，几乎没有什么变化。但是通过LINQ-to-SQL，我能够完全消除第2步，使得数据层能够直接与数据库通信，而无需担心动态SQL语句或潜在的注入漏洞。此外，在开发周期中，我还获得了更简单的更改管理流程的好处。我真的不在乎微软的“官方”立场，因为我已经听说WinForms即将死亡大约五年了，但它仍然存在。

微软首先是一家商业公司。如果他们想继续经营，他们将会给客户提供他们需要的东西，否则客户将会找到更愿意满足他们需求的其他公司。即使只是为了现在仍在使用的遗留应用程序，WinForms也将得到支持，直到Windows操作系统不再支持Windows 95应用程序为止。同样，在某种形式下，LINQ-to-SQL将继续得到支持。在EF中能够无缝地合并现有应用程序运行原始设计（或以最小的开发人员修改）之前，我相信LINQ-to-SQL也将在可预见的未来继续存在。

- Neil T.

Answer 5

我建议使用Entities或NHibernate，Linq会将数据库与领域对象紧密耦合，这些对象会被呈现层所使用。这将导致呈现层与数据库之间产生紧密耦合，这通常是不可取的。

我个人喜欢Entity Framework 4.0，你可以使用它的linq查询和自己编写的POCO对象。它只需为您处理所有数据库/SQL相关的事宜。

- Paul