为什么从ADO切换到ADO.NET？ [英] Why switch from ADO to ADO.NET?

问题描述

我有一些朋友是老派 VB6数据库开发人员，我向他们介绍了.NET及其功能，特别是ADO.NET。

I have some friends who are 'old-school' VB6 database developers and I was telling them about .NET and its features, specifically ADO.NET.

在我们的对话中，他们提出了以下原因，他们宁愿坚持使用ADO而不是转到ADO.NET：

In our conversation, they brought up the following reasons why they would rather stick with ADO than move to ADO.NET:

• 数据集已断开连接（如果电源故障怎么办？）


• 仍然需要编写相同数量的代码


• Dataset <的新选项/ code>， BindingSource 和 TableAdapter 似乎令人困惑


• 相同的代码以编程方式访问数据库，所有更改只是该命令的布局方式

• The Dataset is disconnected (What if power fails?)
• The same amount of code still has to be written
• The new options of Dataset, BindingSource and TableAdapter seem confusing
• the same code is written programatically access the Database, all that changes is how that command is laid out

我在寻找答案或原因为什么在Windows Forms应用程序方面，ADO.NET在数据访问方面要比ADO更好。 ADO.NET提供哪些ADO不提供的内容？它比ADO有什么优势？

I'm looking for answers or reasons why ADO.NET is 'better' than ADO with regards to data access when it comes to Windows Forms applications. What does ADO.NET provide that ADO does not? What does it do better than ADO?

NB：我想举一些不涉及LINQ的示例。

NB: I'd like examples that do not involve LINQ.

推荐答案

一方面，如果它没有损坏，请不要修复它。但另一方面-VB6？真？听起来ADO与ADO.NET的关系不大……

On the one hand, if it ain't broke, don't fix it. But on the other - VB6? Really? Sounds like ADO vs. ADO.NET is small potatoes here...

我认为问题更多是VB与VB.NET，然后是整个代码库，技能设定，其他非技术因素在这里发挥作用。

I think the issue is more VB vs. VB.NET and then the whole code-base, skill-set, other-non-technical-considerations come into play here.

这篇关于为什么从ADO切换到ADO.NET？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！