Linq 2 SQL或Linq实体

时间:2008-12-13 03:10:22

标签: .net linq linq-to-sql linq-to-entities ado

我开始设计一个新的应用程序,我想知道的是人们对Linq2SQL或Linq2Entities的看法,他们认为这是更好的快速开发技术。

我也在研究ADO.net数据服务。

11 个答案:

答案 0 :(得分:13)

是的,同意Slace。

请注意您选择的框架,以确保它满足您的所有需求。

例如,我最近在一个工作项目中强化了实体框架,因为它不能满足我的需求,主要是因为: -

  1. things you can't do in Linq to Entities(例如映射到.net枚举类型(grr)和几乎每一次接收'NotSupportedException'的加重,如果你试图通过调用函数或方法来获得你的linq查询语句中的幻想电话(见链接))。
  2. 缺乏原生的Lazy Loading(我知道有一些工具,例如EF Lazy LoadGen来促进这一点,但这不是我想要加入的东西)。
  3. 除此之外,命令和框架似乎是直截了当的,而且我使用EF的原因是:

    1. 我认为EF的目标更多是企业发展的目标,并认为L2S更适合业余爱好者,而且是一个有限的框架。然而,通过进一步的理解和个人,在EF中我不需要任何东西我无法做到L2S,我对L2S很满意。特别是如果它适合stackoverflow,我可以满足可扩展性和效率。
    2. 多个DBMS的选项'(我现在还没看到这个)
    3. 传闻微软是dropping support and investment on Linq to SQL
    4. 我喜欢这样一个事实:您可以更新EF .edmx中的表和数据库更改,而无需删除现有的模式模型(您必须在Linq to SQL中执行此操作)。虽然,除非您在L2S架构(.dbml)中自定义任何属性,否则不会超级烦人。
    5. 进一步阅读(另一篇SO帖子):
      Is LINQ to SQL Dead or Alive?

      我很想选择EF,我真的不知道如何制造L2S与EF的比赛,如果L2S真的是一个死鸭,耸耸肩。我承认使用EF的主要抱怨是NotSupportedException - 如果我可以在linq中执行方法调用而没有得到这个,我可以绕过延迟加载......

答案 1 :(得分:8)

如果您满足以下设计要求,我就是LINQ to SQL的忠实粉丝:

  • MS SQL Server作为数据库引擎
  • RAD开发
  • 1 - 1类映射就是所需要的

我没有对Entity Framework做过大量工作,但据我所知和我所做的是,当它从LINQ to SQL使用的同一数据库生成时,它没有那么好的性能。 / p>

性能较低是由于Entity Framework的性质,它使用ADO而不是您正在使用的数据库服务器的特定提供程序。

答案 2 :(得分:3)

我想说,对于简单到中等的数据库模式,Linq2SQL运行良好,更易于设置和使用。这是我用于ORM的一些小调整,通过部分类来支持验证和授权/审计。我使用DBML设计器并添加我的表/关系。我更改了DataContext以使其变得抽象,并构建了一个具体的实现,它允许我提供我的表值函数/存储过程(映射到数据上下文中作为方法)的实现,这些实现为审计和授权提供了钩子。我在OnValidate和OnLoad的实体类上实现了部分方法,以在表级执行验证和授权。我发现这几乎是我所需要的。最近,我一直在为具体数据上下文定义一个接口和包装器,以便允许我在单元测试中模拟它。

答案 3 :(得分:3)

与ADO.NET数据服务(您提到)一起使用,实体框架是开箱即用的框架。如果要使用LINQ-to-SQL(通过ADO.NET数据服务)更新数据,则需要执行一些工作来实现IUpdatable。幸运的是,我一直在写关于this week的博客。

我对两者之间的整体想法都有涵盖here,但从那时起我已经软化了一点,见here

基本上,目前我更喜欢LINQ-to-SQL,但我希望EF在下一版本中更有用。因此,我正在努力让LINQ-to-SQL与ADO.NET数据服务一起工作。

答案 4 :(得分:2)

我认为Linq 2 Sql是一个很好的选择。几点:

  • 这真的很快,我记得在L2S测试版期间在Rico Mariani's Performance Tidbits阅读了一篇博客文章,在那里他测得它几乎和普通的旧ADO.Net一样快,那是在测试期间。
  • 如果您愿意,可以同时执行linq查询以及使用存储过程和良好的旧SQL,并且仍然可以为您完成数据对象映射。
  • Stackoverflow使用L2S的事实证明它可以在大型网站上运行。
  • 它比实体框架轻得多,根据您的需要,这是好的和坏的。一般来说,如果您的需求不是超级先进的,通常可以很快解决任何问题。

答案 5 :(得分:1)

我的投票是Linq-to-SQL。它适合您的快速开发场景;易于上手,易于使用。此外,它还可以从Linq表达式生成高效/高效的SQL查询。

Linq-to-Entities非常笨重,如果您尝试使用任何本应将其设置为远离L2S的“高级”功能,那么您将不得不使用XML编辑器开始编辑EDMX模型文件(您'很快就会遇到设计师的“限制”,微软推荐的唯一解决方法/解决方案就是使用XML编辑器手动操作EDMX。最重要的是,它往往会产生非常差/低效的SQL查询。

微软表示,下一版本的Entity Framework将会更好,并将支持L2S的所有好处。然而,下一个版本不会很快发布,所以在那之前L2S是你最好的选择。

答案 6 :(得分:0)

这是一个非常古老的问题,但LinqToSql对最高投票答案的啦啦队关注我。 LinqToSql存在明显的缺点。

Do not use the Visual Studio 2008 LinqToSql O/R Designer

The drawbacks of adopting Linq To Sql

也就是说,EntityFramework也有很多缺点。

现有更多更好的选择(NHibernate现在是最好的选择)。

答案 7 :(得分:0)

我建议您查看ORM的非Microsoft软件解决方案。 nHibernate是一个很好的解决方案,拥有这两个框架的所有好处以及更多。是的,它的学习曲线更陡峭,但流利的nHibernate对此有所帮助。值得努力。

答案 8 :(得分:0)

没有人能说肯定 更好。

两个技术人员都有问题(NHibernate也存在问题)。

我正在使用Linq-to-SQL并且非常满意。对于我的观点,Linq-to-SQL中的问题少于EF ^ _ ^。

答案 9 :(得分:0)

我们认为L2S很棒,直到我们尝试更新。然后它很可悲。我做其他事情时,我的同事正在完成大部分工作。他谈到了EF以及过度配置使得它使用起来混乱的方式。

我建议,既然我们以MSSQL为目标并且不会改变,那么他可能会破解所有数据库提供程序的抽象内容。一段时间后,他告诉我这是一个很好的建议,他的代码更简单,更难以维护。


我很好奇这个答案被投票 down 的基础。它描述了实际经验,并讨论了另一种策略以及该方法的相对成功。向下投票是针对误导,事实不正确或只是简单拖钓的答案。

碰巧我改变了我对整个EF vs L2S事物的立场,但这并没有改变这样一个事实,即仅仅因为它表达了与你自己不同的观点而进行了投票,这种观点是婴儿的,并且与精神完全背道而驰StackOverflow。

答案 10 :(得分:-1)

Linq to SQL如今已经走到了尽头,因为微软不会再对其进行更新了。我为自己的项目使用了一段时间,但我发现它与真正的SQL相比功能不足。当然,在短期内运行似乎更容易,但在应用程序的开发周期中,您会发现您更喜欢SQL的强大功能。

我认为LINQ TO SQL只应该由那些严重依赖于框架的抽象层并且没有时间/精力/欲望来追求SQL的人采用。

您应该记住的另一件事是SQL和您的应用程序之间的额外层有自己的成本。速度差异不是你容易注意到的,但它就在那里。

就我个人而言,我建议那些刚开始学习的人应该直接学习SQL,并且错过LINQ to SQL。