Question

我有点迟到了，决定花些时间学习LINQ。作为练习，我将在MVC 2中重写一个WebForms应用程序（这对我来说也是新的）。我设法在这里找到了一些关于LINQ的主题（Learning about LINQ，Beginners Guide to LINQ，Is LINQ to SQL Dead or Alive?），这引起了我对实体vs SQL的关注。

然而，线程已经超过一年了，我似乎无法找到关于哪个ORM更可取的任何确切信息。实体是否或多或少LINQ to SQL 2.0？它还难以使用吗？

是否有任何理由使用LINQ to SQL，或者我应该跳入实体？我在我现在的雇主那里写的应用程序有很长的生命周期（大约10年），所以我试图选择最好的技术。

Answer 1

在最近一篇关于扩展NerdDinner的文章中，Scott Hanselman谈到了这一点。最后引用：

<强>结论

数据库有很多选择   访问.NET。你会遇到的   旧版或高度调整的DataReader   代码，但没有理由不能   隐藏在存储库中仍然存在   使用愉快。 LINQ to SQL很不错，   轻巧，快速，有几十个   .NET 4中的错误修复，但实体   框架是他们前进的方式   前进。另外，实体框架   4是方式比EF 3.5好，所以我   用它来做任何“大于小”   我正在做的项目，我没有   很麻烦。

当然，我还没有机会玩它，但EF4似乎确实获得了许多专业人士的信任。

Answer 2

有没有理由使用LINQ to SQL，还是应该跳进实体？

我不太客观（作为一个顽固的LinqToSql用户），但这是可以回答的。

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

似乎这些桥梁的开发人员通常称呼一方或另一方，回家。

LinqToSql是来自对象端的ORM。它由C＃团队开发，允许您使用对象来表示数据。在LinqToSql中没有编译器不透明的字符串，编译器会根据映射检查所有查询。

EF是数据方面的ORM。它由ADO团队开发，允许您使用表示为对象的数据。在EF中，有很多不透明的字符串。

查询必须最终针对数据库运行，并且编译器无法证明在运行时可用的数据库与映射匹配（在ORM中为true）。由于数据世界的这种现实，数据团队并不像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);

Answer 3

This article类似于汉塞尔曼的文章。它比较DataReader（他们称之为“连接”数据访问），类型化DataSet（“断开连接”），LINQ to SQL和实体框架。给出了所有方法的详细代码示例，以及每种方法的优缺点。

Answer 4

我在2009年初非常仔细地研究了这两种技术，并且听了很多关于LINQ-to-SQL“即将死亡”的声音。最后，我仍然选择LINQ-to-SQL而不是实体框架，因为我从不喜欢使用ADO.NET和EF提醒我太多了，因为它与数据库紧密相关。

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

构建架构
构建使用架构的数据库对象
构建与数据库对象对话的数据层
构建与数据层对话的业务层

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

首先，微软是一家企业。如果他们想要继续经营，他们会给客户他们想要的东西，否则客户会发现其他人更愿意满足他们的需求。如果仅针对当前仍处于活动状态的旧版应用程序，只要Windows操作系统仍支持Windows 95应用程序，就会支持WinForms。同样，LINQ-to-SQL将继续以某种形式支持。直到它可以无缝地合并到EF中，其中现有应用程序将按原设计运行（或使用最小开发人员修改），我相信LINQ-to-SQL在可预见的未来也将继续存在。

Answer 5

我建议使用Entities或NHibernate，Linq将数据库非常紧密地耦合到您的域对象，然后由您的表示层使用。这将最终导致从表示层到数据库的紧密耦合，这往往是不可取的。

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

LINQ to SQL或Entities，此时？

5 个答案: