LINQ to SQL或Entities,此时？

Question

我玩游戏有点晚了,决定花一些时间学习LINQ.作为练习,我将在MVC 2中重写一个WebForms应用程序(这对我来说也是新的).我在这里找到了一些关于LINQ的主题(学习LINQ,LINQ 初学者指南,LINQ to SQL死或活着？),这引起了我对实体与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);