对于新项目,您会使用Linq to SQL吗?

好吧,这里的答案(也有一些有趣的观点)已经介绍过了,不过我还是要再说一遍。

LinqtoSQL(L2S)是非常通用的,但从我的观点来看,它有点太基本了。在大多数情况下,它在做简单的事情方面做得很好,但只要你多问一点,它就会变得昂贵。这一点也不坏。实际上,我认为LinqtoSQL能够很好地提供实体框架。

以LinqDataSource的自动分页为例。如果您不指定按/分组排序,那么它是相当经济的。将排序或分组加入到组合中,您开始获得性能的高峰(变得非常健谈)。然后,您几乎必须编写自己的分页实现(我承认这并不难)。

我将首先承认,在生成的T-SQL的质量方面,L2S比实体框架具有优势(我应该,因为L2S是专门为查询SQL Server而构建的),并且在概念上和符号上,许多Linq to SQL与EF类似,但在遇到困难时,需要扩展需求并考虑更复杂的问题。指示了实施要求。

如果我从零开始,选择投入个人发展时间,我会选择实体框架。有趣的是,我现在正在开发一个使用L2的项目,它被设计成可以扩展NAD处理重负载,但是当我们遇到一些更“创造性”的需求时,我们常常被迫扩展到SQL金属(例如多对多关系)。

所以…简而言之…我会这样处理:

a)学习linq to sql作为一个简介(微软的ORM模式和技术)。它使您熟悉与实体框架共享的大多数基础知识,以及LINQ风格的查询体验(如果您具有T-SQL的背景,则是一种习得的体验)。

b)一旦您掌握了linq-to-sql的相关知识,我建议您跳到实体框架学习其他的好处(esql等)。

c)在两者中实施概念验证项目并比较结果。

选择NHibernate。它将作为一个概念或实际的ORM保留一段时间。 所以这两个方面都要学习。

在我看来,这整件事真是不合时宜。

微软没有说linq-to-sql会死。他们更指出,它将被合并到实体框架中。

我将专注于使用实体框架作为解决方案,因为我知道大部分linq-to-sql都将被纳入其中。

不管怎样,现在真的没有太大的差别。最大的抱怨是实体框架不是轻量级的。这真的很重要吗,只要你的两层之间有良好的分离?

L2S是,嗯,非常好的方式,正如你所说,不会去任何地方。我为之工作的公司已经将其作为数据访问的标准,我们将其应用于所有领域,从5个小的用户小应用到1000多个用户的企业应用,效果都非常好。

检查亚音速:

http://subsonicproject.com/

我认为 EDM 我们比Linq to SQL的大得多。如果您正在寻找一个简单的ORM,那么我认为LinqToSQL是一种可行的方法。如果计划在具有继承结构的类中构建与具有关系结构的数据库表相关的类,并执行其他高级映射,那么EDM可能是一个不错的选择。

值得一提的是,这个站点是使用linq-to-sql构建的。杰夫谈到了在StackOverflow播客中使用它。

L2S是一种很棒的技术,我再也不会回到老ADO了。

但是正如你提到的,它是一个后座到L2E。L2S是超过了能力,我已经做了大量的应用程序,并已令人难以置信的高兴。但听到它将不再先进,把刀在我身边。所以我去查看了L2e,它是 几乎 同样,当涉及到SQL交互时,在许多方面我发现它更容易,更不用说它的关系处理更有效。有了这样的相似性,选择L2e似乎是合乎逻辑的。

我写了一篇关于切换和比较两个框架的文章: http://naspinski.net/post/Getting-started-with-Linq-To-Entities.aspx

我几乎可以保证您会对这些框架中的任何一个感到满意,它们是开发的天赐之物。简单和避免错误是首屈一指的。我个人会倾向于L2e,因为它会更积极地发展,N L2s。

我在当前的Web项目中大量使用L2S,我相信您会发现最大的问题是关于进行n层数据库开发的最佳方法的文档冲突。

首先,最重要的是,您需要提前实现的是,DataContext对象 只能和工作单位一样长久 ,周期。此外,DataContext是无状态的。一旦您了解了这两个主体,在n层环境中使用LINQ就开始工作得很好。

另一方面,你会看到很多人推荐一些非常糟糕的使用LINQ的方法。不要让你的数据上下文静态化,这是我早先犯的一个错误,它产生了奇迹,直到它不起作用,然后它是绝对可怕的错误数据跨越不同的会话,等等。简单地说,这可能是最大的最大的不使用LINQ,应该在每个文档中用大的粗体字写。此外,在会话变量中持久化DataContext也是一个同样糟糕的主意。

我遇到的另一个主要问题是在执行断开连接的更新时,您需要在整个调用中使用相同的DataContext。例如:

    public static void UpdateUser(UserLibrary.User user) {
        using (UserLibraryDataContext dc = new UserLibraryDataContext(_conStr))
        {
            UserLibrary.User newUser = (from user2 in dc.Users where user2.UserID == user.UserID select user2).FirstOrDefault();
            newUser.Email = user.Email;
            newUser.FirstName = user.FirstName;
            newUser.LastName = user.LastName;
            dc.SubmitChanges();
        }        

您不能简单地传入在其他DataContext中创建的用户并期望更新工作,除非您设置了DataContext.ObjectTrackingEnabled=false,这是我不推荐的。相反,在同一个DataContext中,您应该检索现有对象,更新其值,然后提交这些更改。在同一个数据上下文中保留所有类似的任务。

不过,我还是推荐L2S,一旦你解决了一些琐碎的问题(如上面所述),它是一项伟大的技术,而且绝对是一个节省时间的工具。不过,我建议您在DAL周围做一个薄的包装,这样您可以很容易地更改。我正在考虑(出于经济原因)将代码的一部分移植到使用OpenAccess ORM->MySQL进行数据访问的一部分,并且使用适当定义的层,此任务只需几个小时。

我同意回声风暴。L2S适合您的需求。而且很容易和…

如果你设计好你的应用程序,隔离好你的数据访问层,你应该使用L2S。根据我从你的帖子推断,这不是一个大项目,所以L2S应该可以满足你的要求,而简单的老ADO.NET只是一个不,实体框架,是…别用它,好吗? 不管怎样,如果你很好地隔离了你的DAL,你可以在将来交换L2到其他东西,如果项目增长的话。即使L2S不去任何地方,也不去任何地方。微软停止了对IT的投资,但它不会被弃用或是其他什么东西,所以它仍然是一项安全的投资。 或者,你应该评估NHiberinate,它是简单和成熟的。