讨论：DAO诉ADODB的利弊 [英] Discussion: Pros and Cons of DAO v ADODB

问题描述

我不知道在哪里讨论这个。现在我很满意将这个问题提交给你的专家，看看会发生什么。


我今天下午与潜在的雇主进行了长时间的电话交谈，获得了Access / VBA开发者职位。他声称ADO远远优于DAO，事实上，听到他谈论它，你可能会认为DAO是一个被弃用的功能。他声称微软将在未来的Access / VBA版本中取消DAO。


我试图调查此事，结果大不相同，这位绅士告诉他们对我说相反的人...... DAO是首选的数据访问方法。我的大多数项目都使用DAO，因为我发现每当我使用ADO时，所需的编码量似乎都会更大。


我不是在寻找对DAO的同情所以我可以保持我所有的项目，而不仅仅是对最佳实践的客观评估。如果你们想让我在问题部分打开一个帖子，请告诉我。谢谢。


Pat

解决方案

这应该是一个有趣的讨论Pat，我自己也听说过这个最近也是。这是我对发生的事情及其发展方向的理解。


最初，DAO是为Access或Jet特定对象设计和使用的。它的局限性在于它没有很好地处理外部表格或记录集。另一方面，ADODB更具通用性。然而，ADODB并没有我们期望使用Access的铃声和口哨，因此DAO通常在内部用于Access / Jet。


然后访问团队的某个人（或者其他地方 - 我不知道）有想法将ADODB全面标准化（我的意思是Access / Jet和外表）。该产品的后续版本有他们的记录集和在ADODB上构建的默认库。


后来，他们意识到实际上，ADODB在处理外部/外部记录集方面做得很好，但是与人们习惯使用DAO完全匹配，因此2010年（我认为 - 甚至可能是2007年，但我认为是2010年）恢复使用DAO作为标准和默认值。我们甚至开始看到一些问题，其中2010年的项目失败是在2007年设计的，因为该项目使用的ADODB参考在2010年默认不再可用。


所以，对于我们这些仍然使用DAO支持我们以前在Access中可用的所有功能的人来说，好消息是那些推动ADODB成为所有人库的人似乎我们已经知道它从未像那样简单。但请记住，DAO对外部/外部数据源的处理并不好。 ADODB仍然是我想说的选择。

NeoPa，

最后一行，第一行我认为你的意思是DAO不是ADO，否则我同意一切。转向ADO是2000年和2002年，但在2003年回到DAO。


Tom Wickerath详细讨论了Access MVP
http://www.accessmvp.com/TWickerath/articles/adodao.htm


显然，两者可以在同一个项目中共存，但必须明确引用。对于Access 2010，您需要检查是否存在对c：\Program Files \Common Files \ System \ ADO \ msado25.tlb的引用。 我只是想知道msado25,27& 28吗？

就个人而言，我从未测试过ADO，因为我所有的后端SQL Server都使用了ODBC。我刚刚开始关注网络开发并需要网络表格的ADO（我相信）

S7

也许这是一个问题我从来没有在另一个中没有的功能。我的意思是，如果你正在做一些事情，比如连接到数据源并通过客户端的记录集进行填充和枚举 - 我看不到其中一个优势。


让我们具体化并举一个简单的例子。我写了一些ADO来进行文本框搜索授权号码（PIN）并拉出授权名称和到期日期并将其显示在表单上：

展开 | 选择 | Wrap | 行号

I wasn''t sure where to discuss this. For now I''m content to bring the issue up with you experts and see what happens.

I had a long phone conversation this afternoon with a potential employer, for an Access/VBA developer position. He made a claim that ADO is far superior to DAO, and in fact to hear him talk about it you might think that DAO is a deprecated feature. He claimed that Microsoft will do away with DAO in future releases of Access/VBA.

I''ve tried to look into this matter, with wildly varying results ranging from what this gentleman told me, to people saying just the opposite...that DAO is the preferred data access method. Most of my projects utilize DAO, because I find that whenever I use ADO the amount of coding required seems to be greater.

I''m not looking for sympathy toward DAO so that I can keep all my projects as they are, rather just an objective assessment of what the best practice is. If you guys want me to open a thread up in the questions section, then let me know. Thanks.

Pat

解决方案

This should be an interesting discussion Pat, and I''ve heard talk of it myself recently too. Here''s my understanding of what happened and where it''s headed.

Originally, DAO was designed and used for Access or Jet specific objects. It was limited in that it didn''t handle outside tables or recordsets too well. ADODB, on the other hand, being more general purpose, did. ADODB however, didn''t have quite the bells and whistles that we expect from using Access, so DAO was used generally internally to Access/Jet.

Then someone in the Access team (or maybe elsewhere - I don''t know) had the idea to standardise things towards ADODB across the board (by which I mean for Access/Jet and outside tables). Later versions of the product had their recordsets and the default library built on ADODB.

Later still, they realised that actually, ADODB does a fine job of handling foreign/outside recordsets, but can''t quite match what people are used to using DAO, hence 2010 (I think - It may even have been 2007, but I think 2010) reverted back to using DAO as standard and default. We are even starting to see a few questions where projects fail in 2010 that were designed in 2007 because the ADODB reference, which the project was built to use, is no longer available by default in 2010.

So, the good news for those of us that still make use of DAO to support all the features we''re used to having available in Access, is that those people who were pushing for ADODB as a library for all seem to have learnt that it was never quite as simple as that. But remember DAO doesn''t do well with foreign/external data sources. ADODB is still the choice for those I would say.

NeoPa,
Last para, first line I think you mean DAO not ADO, otherwise i agree with everything. The move to ADO was 2000 & 2002 but back to DAO in 2003.

This is discussed at length by Tom Wickerath an Access MVP
http://www.accessmvp.com/TWickerath/articles/adodao.htm

Obviously both can coexist in the same project but must be referenced explicitly. In the case of Access 2010 you need to check there is a referent to c:\Program Files\Common Files\System\ADO\msado25.tlb. I just wonder what msado25,27 & 28 do?
Personally, I have never tested ADO as all my backend SQL Server stuff uses ODBC. I''m just starting to look at web-developments and will need ADO for web forms (I believe)
S7

Perhaps it''s a question of my never having needed functionality in one that is not available in the other. I mean, if you''re doing something like connecting to the data source and populating and enumerating through a recordset on the client side - I can''t see an advantage in one over the other.

Let''s make it concrete and take a simple example. I wrote some ADO to do a text box search for a grant number (PIN) and pull the grant name and expiration date and display them on the form:

Expand|Select|Wrap|Line Numbers

这篇关于讨论：DAO诉ADODB的利弊的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！