为什么从 ADO 切换到 ADO.NET？
我有一些朋友是“老派”VB6 数据库开发人员，我向他们介绍 .NET 及其功能，特别是 ADO.NET。
在我们的谈话中，他们提出了以下为什么他们宁愿坚持使用 ADO 而不是转向 ADO.NET 的原因：
- 数据集已断开连接（如果断电怎么办？）
- 仍然需要编写相同数量的代码
- < 的新选项code>Dataset、
BindingSource和TableAdapter似乎令人困惑， - 的代码是以编程方式编写的，访问数据库，所有的变化就是该命令的布局方式
相同 当涉及到 Windows 窗体应用程序时，寻找 ADO.NET 在数据访问方面比 ADO “更好”的答案或原因。 ADO.NET 提供了哪些 ADO 没有提供的功能？ 它比 ADO 做得更好吗？
注意：我想要不涉及 LINQ 的示例。
I have some friends who are 'old-school' VB6 database developers and I was telling them about .NET and its features, specifically ADO.NET.
In our conversation, they brought up the following reasons why they would rather stick with ADO than move to ADO.NET:
- The Dataset is disconnected (What if power fails?)
- The same amount of code still has to be written
- The new options of
Dataset,BindingSourceandTableAdapterseem confusing - the same code is written programatically access the Database, all that changes is how that command is laid out
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: I'd like examples that do not involve LINQ.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
一方面，如果它没有坏，就不要修理它。 但另一方面 - VB6？ 真的吗？ 听起来 ADO 与 ADO.NET 在这里只是小事...
我认为问题更多的是 VB 与 VB.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...
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 是不受支持的基于 COM 的技术。 截至 2008 年 3 月，VB 6.0 已成为不再受支持的技术。DAO、RDO、ADO 都是已过了其鼎盛时期近十年的技术。
ADO.NET 是用于数据访问的现代工具集。 特别是，LINQ to SQL 和实体框架将数据访问提升到了新的高度。
ADO is unsupported COM-based technology. VB 6.0 is end of life unsupported technology as of March 2008. DAO, RDO, ADO are all technologies that are nearly a decade past their prime.
ADO.NET is a modern toolset for data access. In particular, LINQ to SQL and the Entity Framework take data access to new heights.
在旧版 VB6 应用程序中使用 ADO 没有任何问题。 如果这些应用程序运行正常，就没有理由更改它们。
我认为在 .Net 中编程的人不会太想尝试使用 ADO，因为当您尝试使用时，感觉就像是一项黑客工作。 随他们去吧。
There's nothing wrong with using ADO in legacy VB6 applications. And if these applications are functioning correctly there's no reason to change them.
I don't think anyone programming in .Net will be too tempted to try to use ADO since it feels like such a hack job when you try to. Just let them be.
简单的答案：不要说服他们...
让他们查看 LINQ to SQL（或者更好的是 LINQ to Entities）
Simple answer: don't convince them...
Have them look at LINQ to SQL (or better yet LINQ to Entities)
在我的日常工作中，能够让人们转向 ADO.NET 的最大问题之一是 ADO（VB6 风格）都是 COM，使用 ADO.NET 可以获得更好的性能。
One of the biggest issues that was able to get people to switch to ADO.NET at my day job was the fact that ADO (VB6 flavor) is all COM, you get better performance with ADO.NET.
我猜测如果记录集仍然连接并且服务器断电，用户会立即在他们的应用程序中收到提示，然后再继续输入不会保存的数据？
内存垃圾回收怎么样？
在 .net 中分发更新更容易。
我想如果你在 VB 6 中有很多用于 winform 应用程序的代码，为什么要改变呢？ 也许如果您使用 VB.NET 开始一个新项目，您可以展示一些其他好处，例如在表适配器中包含多个表（不能说我已经利用了这一点）。
I'm guessing if the recordset is still connected and the power goes out on the server, the user would get prompted immediately in their app before they continue to enter data that won't get saved?
How about memory garbage collection?
Distributing updates is easier in .net.
I guess if you have a lot of code in VB 6 for winform apps why change? Maybe if you start a new project using VB.NET you can show some other benefits like including multiple tables in a table adapter (Can't say I've taken advantage of that).
我自己更喜欢 ADO.NET，但为了平衡，经典 ADO 相对于 ADO.NET 有一个优点：可以说它更可用。
由 .NET 框架架构师编写，位于 .NET 框架设计指南 第二版第 25 页。
I prefer ADO.NET myself, but just for balance, there is one advantage of classic ADO over ADO.NET: it is arguably more usable.
Written by the architects of the .NET framework, in the .NET Framework Design Guidelines 2nd Edition page 25.