【问题标题】:Difference between Linq to Sql, Linq, Typed Datasets, ADO.NETLinq to Sql、Linq、Typed Datasets、ADO.NET 之间的区别
【发布时间】:2009-07-04 10:04:25
【问题描述】:

我一直在想这个问题。现在好像有很多方法我不知道什么时候用什么?或者,如果有学习它们的意义。就像我不知道他们是否基本上做所有相同的事情,并且基本上坚持一个直到你掌握它然后也许看看其他的。

所以当我参加作为我计划一部分的 ASP.NET 课程时。

我们最初确实喜欢 ADO.NET,我们只是在代码中使用 SQL 语句编写所有内容。然后我们转向 3 层架构。这是通过创建类似的类并拥有返回内容的数据集来完成的。

SQL 是在课堂上编写的。我个人从来没有真正喜欢过这种方式,因为我总是觉得试图正确引用引号很烦人,而且总体上不喜欢它。

然后我在 Asp.net 网站上找到了我非常喜欢的 3 层拱门教程。他们使用类型化的数据集。您将数据集文件添加到 DAL 文件夹中,然后您将通过 GUI 制作表格适配器和东西。然后,您将在这些 GUI 中编写代码,我发现它是完美的解决方案,因为现在我的 SQL 代码远离我的代码,我不必担心引号和所有这些东西不正确或关闭连接和东西加上它甚至还有一个 SQL GUI 构建器!

然后我会在 BLL 文件夹中创建文件并创建一个属性来获取表适配器并编写我的业务层逻辑。

我唯一不喜欢的是,如果我的东西试图返回一些新行,它会被输入,它会发疯。

所以当我必须加入表格时,我通常必须制作一个新的表格适配器。

现在好像有这么多。

  • Linq -> 有人说会取代 ADO.NET,有人说不会。
  • Linq 到 sql
  • ado.net

我不确定是否所有这些都可能不是。

在写这篇文章之前,我快速检查了一下 linq to sql 是关于什么的,并看到一些帖子说 MS 正在扼杀它。他们从 2008 年开始,所以我不知道这是否属实,但我注意到几乎所有 MVC 书籍都使用 linq to sql,所以我认为不是。

那么值得切换到不同的东西然后输入数据集吗?还是分别用于不同的情况?

【问题讨论】:

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


【解决方案1】:

LINQ 本身只是一种融入 C# 3.0 的基础技术(“语言集成查询”) - 它与数据库本身没有相关。 LINQ 可用于各种事物 - 数据库、XML、内存中的对象、Entity Framework 实体、Active Directory - 你可以命名它。

Linq-To-SQL 是一种轻量级、直接的、仅限 MS-SQLServer 的技术,它允许您在 .NET 应用程序中将 SQL Server 表作为真实对象轻松而良好地使用。它是一个“对象关系映射器”,可以更轻松地处理数据库。它只是 SQL Server,Microsoft 不会进一步扩展它 - 它在 .NET 4.0 中也可用,但不会再进一步​​开发。

ADO.NET 是 .NET 中的基础数据访问技术 - 它使您可以访问各种数据存储,包括关系型和非关系型。这是一项非常基础的技术——您以非常低级的原始方式处理数据。

最重要的是,您拥有 ADO.NET 数据集,它有点像 Linq-to-SQL,因为它们使处理数据库变得更加容易。与 Linq-to-SQL 不同,您不是在 .NET 代码中处理来自域模型的 对象,而是像处理面向数据库的行和列一样存在于数据库中。它更直接地表示数据库中的内容,位于较低级别,与您的数据库布局紧密耦合,并且不像 Linq-To-SQL 对象那样“好”且易于使用 - 您处理低级行和列及其值。

如果您现在有选择,并且除了 SQL Server 之外不需要任何东西,我强烈建议您查看 Linq-to-SQL - 从原始数据库表到真正好用且易于使用的 .NET 对象的映射让您的生活更轻松!

马克

【讨论】:

  • so... Entity Framework 相当于 Linq-to-SQL?
  • @mmcrae:Linq-to-SQL 和 EF 都是 object-relational mapper 产品 - 所以是的,他们做同样的事情 - 或多或少 - 所以他们的“工作” 或者它们在 IT 世界中的用途是相同的,是的 - 但技术和功能并不相同 - EF 提供的功能比 Linq-to-SQL 提供的要多得多
【解决方案2】:

阐明 LINQ-to-SQL 的故事;它并没有“死”——它是 .NET 框架中非常受支持的部分,并且正在积极开发中(Redmond 有一个 LINQ-to-SQL 团队)。

关键是新特性的开发主要是进入 EF,包括(希望)弥合 LINQ-to-SQL(通常非常流行)和 EF(已经在很多方面受到批评)。

例如,EF 4.0 支持 POCO 对象,如 LINQ-to-SQL。

就个人而言,我仍然是 LINQ-to-SQL 的粉丝,并且很乐意将它用于新构建 - 但我会将所有这些隐藏在存储库接口后面,以便我可以随意将其交换到任何工具:

  • 原始 ADO.NET
  • LINQ-to-SQL
  • NHibernate
  • LLBLGenPro
  • 实体框架

不会触摸的一件事是DataSet ;-p

【讨论】:

  • 嗯,现在我不确定该使用什么。这里的每个人似乎都不喜欢数据集(不知道为什么)。所以我不确定为什么不使用实体框架呢?我也听说过这个存储库接口。那是存储库模式对吗?我听说它应该使单元测试更容易。虽然我对此了解不多,但我不确定它会如何做你所说的?难道我还没有正确的新语法中的所有代码。我会喜欢这样的一些例子。我通常尽量远离设计模式。不是因为它们不好,我只是觉得它势不可挡。我还处于学习的菜鸟阶段
  • 当你被一个又一个设计模式轰炸而我坐在那里想我几乎不能做基础的时候,我发现这非常困难。然而,我开始着手进行单元测试,因此我可能会将其作为我将尝试学习的设计模式。即使我在单元测试中看到他们也使用了一些工厂模式。但是学习我的下一个项目太多了. ELMAH 7. Jquery
  • 哦,我完全同意模式过度使用。存储库模式恰好对 IMO 非常有用,它允许单元测试和抽象。关于实现存储库抽象有很多观点 - 谷歌应该有很多。
【解决方案3】:

我想说,如果您在使用 ADO.NET 的 SQL 语句中正确获取引号时遇到问题,那么您可能是以错误的方式构建 SQL 语句。倾向于 SQL injection 或至少:乱码。

LINQ to SQL 使用 ADO.NET 来做这件事。它基本上是Object-relational mapping (ORM) 工具与新查询语法的组合。我不会在 LINQ to SQL 上投入时间,因为 Microsoft 已宣布它的生命周期结束。

Entity Framework 是 LINQ to SQL 的替代品。它是一个 ORM 工具,带有它自己的 SQL,如查询语言,Entity SQL。您可以在其之上使用 LINQ,以便大多数简单查询与 LINQ to SQL 中的完全相同。

使用什么方法很大程度上取决于您要执行的操作。我不会使用类型化的数据集(或任何数据集)。我猜这是个人喜好,但如果您可以创建类型化的数据集,则最好进行全面的对象关系映射。

了解基本的 ADO.NET 是一项很有用的技能,但是你看它。尤其是如果您需要更新数据库中的多条记录而不首先检索该数据,您将始终编写 SQL 语句。我建议为这些情况创建存储过程,您可以使用普通的 ADO.NET 调用它们,或者您可以将它们添加到实体框架中的模型中并通过那里调用它们。

实体框架为您提供了一些数据库独立性(与 LINQ to SQL 不同)。周围有 Oracle 的实现,但我个人没有经验。据我所知,如果你在做半复杂的工作,他们会施加一些不受欢迎的限制。

【讨论】:

  • 好吧,正如我提到的,这是我在课堂学习的时候,不知道发生了什么。我敢肯定,如果我今天回去做,他们会好很多。我只有那些记忆,这就是我喜欢类型化数据集的原因。
猜你喜欢
  • 2010-10-30
  • 1970-01-01
  • 2011-08-25
  • 1970-01-01
  • 2011-01-27
  • 1970-01-01
  • 1970-01-01
  • 2011-01-15
  • 1970-01-01
相关资源
最近更新 更多