linq to sql vs ado.net实体

时间:2010-01-29 18:18:12

标签: sql-server linq-to-sql entity-framework linq-to-entities

如果我使用SQL Server作为我的数据库服务,是否有任何令人信服的理由来查看Linq to SQL上的LINQ to Entities?

3 个答案:

答案 0 :(得分:2)

Linq to SQL不再被积极开发 - 他们将资源集中在实体框架上。此外,EF更强大,并允许在Linq to Sql中忽略的许多更高级的场景。

在您调查ORM时,我会认真看看NHibernate。它的使用寿命比微软的产品要长得多,而且用途广泛。

答案 1 :(得分:1)

如果您只想在类和表之间进行一对一映射,那么Linq to SQL就足够了,可以将其视为数据集的“对象”版本。

EF可以让你做更复杂的映射。

从长远来看,微软正在将每个人推向EF,但EF使用起来更为复杂。在.net 4发布之前,使用EF进行测试驱动开发非常困难。

如果要隐藏一组接口背后的所有数据访问并根据从数据库中获取的行自己创建域对象,那么Linq to SQL在短期内是一个不错的选择。但是你可能被迫长期转移到EF。

如果您希望使用ORM将域对象映射到数据库,那么EF是一个更好的对象,但也会考虑nhibernate

如果你在几年后回来,你的问题的答案将是EF,但目前尚不清楚......

答案 2 :(得分:0)

有很多令人信服的理由选择实体框架而不是LinqToSql,但你只需要一个:

微软更愿意使用Entity Framework。微软将其大部分ORM开发资源置于EF之后。那是他们未来的道路。

不幸的是,EF 3.5在很多方面都是LinqToSql的重要一步,所以微软真的推动了很多想要使用EF的人回到LinqToSql。使用EF 4.0,EF并不完全等同于LinqToSql,但它更接近。

EF 4.0确实提供了许多LinqToSql目前不支持且可能永远不会支持的功能。

远离EF 3.5。如果您想要一个ORM for .NET 3.5,请使用NHibernate。对于.NET 4.0,请在NHibernate和Entity Framework之间进行选择。在.NET 4.0中使用LinqToSql并不是一个的理由。