为什么不使用DAO？ [英] Why not use DAO?

问题描述

我喜欢ADO.NET，但我发现OLEDB速度慢得令人无法接受。最后一次

我试图使用Jet数据库进行本地数据存储，我放弃了，并且

将我的数据写入二进制平面文件。这一次，我真的需要

来使用关系数据库，所以我一直在充分利用OLEDB和

诅咒其性能。

DAODataAdapter类，它使用DAO实现DataAdapter。对于.mdb文件的

更新，它比OLEDbDataAdapter快4倍！


现在我陷入了两难境地。我应该在我的闪亮新的NET

申请中使用DAO吗？我知道DAO已被弃用;我知道COM对象有内存

问题并使用与.NET对象不同的架构;我知道这一点，

但是我不会忽视性能上的4倍差异。


因此，我的计划是使用DAO和该死的后果。我在这里张贴了
只是为了找出其他经验丰富的NET开发者

想一想。当然，我不是第一个沿着这条路走下去的人，而且我很好奇其他人做出的选择。

-TC

I love ADO.NET, but I find OLEDB to be unacceptably slow. The last time
I tried to use a Jet database for local data storage, I gave up and
wrote my data to a binary flat file instead. This time, I really need
to use a relational database, so I''ve been making the best of OLEDB and
cursing its performance.

A few days ago, however, I tried an experiment and wrote a
DAODataAdapter class, which implements DataAdapter using DAO. For
updates to an .mdb file, it is 4x faster than OLEDbDataAdapter!

So now I have a dilemma. Should I use DAO in my shiny new NET
application? I know DAO is deprecated; I know COM objects have memory
issues and use a different architecture than NET objects; I know this,
but I''m not going to ignore a 4x difference in performance.

My plan, therefore, is to use DAO and damn the consequences. I''m
posting here just to find out what other experienced NET developers
think about this. Certainly, I''m not the first person to go down this
road, and I''m curious what choices others have made.
-TC

推荐答案

嗯，你就这样做了。


我希望没有人告诉过你不要用DAO。但是，如果他们这样做，我希望他们真正意味着b $ b。建议你不要使用DAO。，这是两个完全不同的陈述。

。 br />

我，我很惊讶您报告了这种速度的差异，但是然后

对于.mdb文件的更新，它是快4倍是一个相当宽泛的刷子

声明。


我想要看到你在比较OleDB和
$ b $的代码b DAO。

" TC" < go ********* @ yahoo.comwrote in message

news：11 ********************* *@73g2000cwn.googlegro ups.com ...

Well you just do that :)

I hope that nobody has ever told you "Don''t use DAO." but if they did I hope
they really meant "It is recommended that you don''t use DAO.", which are two
totally different statements.

I, myself, am surprised that you report such a ''speed'' difference but then
"For updates to an .mdb file, it is 4x faster" is a pretty broadbrush
statement.

I, for one would like to see the code you are comparing both for OleDB and
DAO.
"TC" <go*********@yahoo.comwrote in message
news:11**********************@73g2000cwn.googlegro ups.com...

>我喜欢ADO.NET，但我发现OLEDB速度慢得令人无法接受。最后一次

我试图使用Jet数据库进行本地数据存储，我放弃了，并且

将我的数据写入二进制平面文件。这一次，我真的需要

来使用关系数据库，所以我一直在充分利用OLEDB和

诅咒其性能。

DAODataAdapter类，它使用DAO实现DataAdapter。对于.mdb文件的

更新，它比OLEDbDataAdapter快4倍！


现在我陷入了两难境地。我应该在我的闪亮新的NET

申请中使用DAO吗？我知道DAO已被弃用;我知道COM对象有内存

问题并使用与.NET对象不同的架构;我知道这一点，

但是我不会忽视性能上的4倍差异。


因此，我的计划是使用DAO和该死的后果。我在这里张贴了
只是为了找出其他经验丰富的NET开发者

想一想。当然，我不是第一个沿着这条路走下去的人，我很好奇别人做了什么选择。


-TC

>I love ADO.NET, but I find OLEDB to be unacceptably slow. The last time
I tried to use a Jet database for local data storage, I gave up and
wrote my data to a binary flat file instead. This time, I really need
to use a relational database, so I''ve been making the best of OLEDB and
cursing its performance.

A few days ago, however, I tried an experiment and wrote a
DAODataAdapter class, which implements DataAdapter using DAO. For
updates to an .mdb file, it is 4x faster than OLEDbDataAdapter!

So now I have a dilemma. Should I use DAO in my shiny new NET
application? I know DAO is deprecated; I know COM objects have memory
issues and use a different architecture than NET objects; I know this,
but I''m not going to ignore a 4x difference in performance.

My plan, therefore, is to use DAO and damn the consequences. I''m
posting here just to find out what other experienced NET developers
think about this. Certainly, I''m not the first person to go down this
road, and I''m curious what choices others have made.
-TC

TC，


我和Stephany有相反的看法，我肯定不会去这条路来自

DAO。此外，我不会使用Jet Engine为新的应用程序提供任何方向。我们不知道在新的操作系统上会有多长时间。所以

只是去SQLExpress，因为在这些新闻组中经常被告知我的想法是一个更好的方法。


我是斯蒂芬妮对你的代码感到好奇，虽然众所周知，DAO比其他所有代码都要快一些。


Cor

" TC" < go ********* @ yahoo.comschreef in bericht

news：11 ********************* *@73g2000cwn.googlegro ups.com ...

TC,

I have an opposite opinion as Stephany, I surely would not go the road from
DAO. Even moreover, I would not go any direction using the Jet Engine for
new applications. We don''t know how long it will be on newer OS. Therefore
just go to SQLExpress as is often told in these newsgroups is in my idea a
better approach.

I am with Stephany curious about your code, although it is known that DAO is
slightly quicker than all other that is made after it.

Cor
"TC" <go*********@yahoo.comschreef in bericht
news:11**********************@73g2000cwn.googlegro ups.com...

>我喜欢ADO.NET，但我发现OLEDB速度慢得令人无法接受。最后一次

我试图使用Jet数据库进行本地数据存储，我放弃了，并且

将我的数据写入二进制平面文件。这一次，我真的需要

来使用关系数据库，所以我一直在充分利用OLEDB和

诅咒其性能。

DAODataAdapter类，它使用DAO实现DataAdapter。对于.mdb文件的

更新，它比OLEDbDataAdapter快4倍！


现在我陷入了两难境地。我应该在我的闪亮新的NET

申请中使用DAO吗？我知道DAO已被弃用;我知道COM对象有内存

问题并使用与.NET对象不同的架构;我知道这一点，

但是我不会忽视性能上的4倍差异。


因此，我的计划是使用DAO和该死的后果。我在这里张贴了
只是为了找出其他经验丰富的NET开发者

想一想。当然，我不是第一个沿着这条路走下去的人，我很好奇别人做了什么选择。


-TC

>I love ADO.NET, but I find OLEDB to be unacceptably slow. The last time
I tried to use a Jet database for local data storage, I gave up and
wrote my data to a binary flat file instead. This time, I really need
to use a relational database, so I''ve been making the best of OLEDB and
cursing its performance.

A few days ago, however, I tried an experiment and wrote a
DAODataAdapter class, which implements DataAdapter using DAO. For
updates to an .mdb file, it is 4x faster than OLEDbDataAdapter!

So now I have a dilemma. Should I use DAO in my shiny new NET
application? I know DAO is deprecated; I know COM objects have memory
issues and use a different architecture than NET objects; I know this,
but I''m not going to ignore a 4x difference in performance.

My plan, therefore, is to use DAO and damn the consequences. I''m
posting here just to find out what other experienced NET developers
think about this. Certainly, I''m not the first person to go down this
road, and I''m curious what choices others have made.
-TC

特别适合Stephany ..


让我成为告诉你的人;不要使用DAO并且我的意思是保持

远离它我认为只有一个例外当你仍然应该

使用它

你是一个VB6程序员，需要维护一个用DAO编写的编程


在VB.Net（所有版本）中它是肯定的没有去

为什么？好吧，因为它绝对是不可否认的过时，我也不会因为我们有ADO.Net

DAO在大多数情况下在访问时更快数据库,,,没有

讨论那个（DAO也比经典的ADO更快）


但是我会建议你在你的mdf中使用mdf项目，这将爆炸

远离Access的性能，并在您新部署的应用程序中使用过时的

产品。


顺便说一句，带有firehose光标的标准ADO记录集也比现在的ADO.Net表适配器快得多，但是如果你使用

datareader那么他们执行ADO.Net甚至可能在SQL服务器上更快

因为它使用优化的驱动程序所以不要将梨与苹果比较:-)

问候


Michel Posseth [MCP]


" Cor Ligthert [MVP]" < no ************ @ planet.nlschreef in bericht

news：eu ************** @ TK2MSFTNGP06.phx .gbl ...

Well especially for Stephany ..

Let me be the one that tells you "don`t use DAO" and with that i mean stay
away of it there is only one exception in my opinion when you should still
use it
"You are a VB6 programmer , and need to maintain a prog written with DAO "

In VB.Net ( all versions ) it is a definite no go
Why ?? well because it is absolutely undeniable obsolete , i would also not
recomend classic ADO cause it is obsolete because we have ADO.Net
DAO is in most situations faster on a Access database ,,, there is no
discussion about that ( DAO was also faster as classic ADO )

However i would recomend you to use a mdf in your projects , this will blast
away the perfomance of Access and is the bether way as using obsolete
products in your newly to deploy application.

By the way a standard ADO recordset with a firehose cursor is also much
faster as a typical ADO.Net table adapter aproach however if you use a
datareader they perform equall ADO.Net might even be faster on SQL server
cause it uses a optimized driver so don`t compare pears with apples :-)
regards

Michel Posseth [MCP]

"Cor Ligthert [MVP]" <no************@planet.nlschreef in bericht
news:eu**************@TK2MSFTNGP06.phx.gbl...

TC，


我对斯蒂芬妮有一个相反的看法，我肯定不会走这条路
来自DAO的
。此外，对于新应用程序，我不会使用Jet Engine

。我们不知道在新的操作系统上会有多长时间。

因此，只需按照SQLExpress进行操作，因为在这些新闻组中经常被告知

我的想法是更好的方法。


我和Stephany对你的代码很好奇，虽然众所周知DAO

比其他所有代码都要快一些。 />

Cor


" TC" < go ********* @ yahoo.comschreef in bericht

news：11 ********************* *@73g2000cwn.googlegro ups.com ...

TC,

I have an opposite opinion as Stephany, I surely would not go the road
from DAO. Even moreover, I would not go any direction using the Jet Engine
for new applications. We don''t know how long it will be on newer OS.
Therefore just go to SQLExpress as is often told in these newsgroups is in
my idea a better approach.

I am with Stephany curious about your code, although it is known that DAO
is slightly quicker than all other that is made after it.

Cor
"TC" <go*********@yahoo.comschreef in bericht
news:11**********************@73g2000cwn.googlegro ups.com...

>>我喜欢ADO.NET，但我发现OLEDB速度慢得令人无法接受。最后一次
我试图使用Jet数据库进行本地数据存储，我放弃了将数据写入二进制平面文件。这次，我真的需要使用关系数据库，所以我一直在利用OLEDB并诅咒其性能。

几天前，然而，我尝试了一个实验并写了一个
DAODataAdapter类，它使用DAO实现DataAdapter。对于.mdb文件的
更新，它比OLEDbDataAdapter快4倍！

所以现在我陷入了两难境地。我应该在我的闪亮的新.NET应用程序中使用DAO吗？我知道DAO已被弃用;我知道COM对象有内存问题，并使用与.NET对象不同的架构;我知道这一点，
但我不会忽视性能上的4倍差异。

因此，我的计划是使用DAO并告知后果。我在这里发帖只是为了找出其他经验丰富的NET开发人员对此的看法。当然，我不是第一个沿着这条路走下去的人，我很好奇别人做出了什么选择。

-TC

>>I love ADO.NET, but I find OLEDB to be unacceptably slow. The last time
I tried to use a Jet database for local data storage, I gave up and
wrote my data to a binary flat file instead. This time, I really need
to use a relational database, so I''ve been making the best of OLEDB and
cursing its performance.

A few days ago, however, I tried an experiment and wrote a
DAODataAdapter class, which implements DataAdapter using DAO. For
updates to an .mdb file, it is 4x faster than OLEDbDataAdapter!

So now I have a dilemma. Should I use DAO in my shiny new NET
application? I know DAO is deprecated; I know COM objects have memory
issues and use a different architecture than NET objects; I know this,
but I''m not going to ignore a 4x difference in performance.

My plan, therefore, is to use DAO and damn the consequences. I''m
posting here just to find out what other experienced NET developers
think about this. Certainly, I''m not the first person to go down this
road, and I''m curious what choices others have made.
-TC

这篇关于为什么不使用DAO？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！