ADO.NET 与 ADO.NET 实体框架
ADO.NET 和 ADO.NET 实体框架哪个更快?
What is faster - ADO.NET or ADO.NET Entity Framework?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
ADO.NET 和 ADO.NET 实体框架哪个更快?
What is faster - ADO.NET or ADO.NET Entity Framework?
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(2)
没有什么比 ADO.NET 数据读取器更快。
实体框架也在“地下室”使用它。
但是实体框架可以帮助您从数据库映射到对象..
使用 ADO.NET,您必须自己完成此操作。
这取决于你如何编程它的速度有多快..
当您使用 ADO.NET 数据表作为“对象”时。它们比普通对象要慢一些并且占用内存......
Nothing is faster than an ADO.NET datareader.
Entity framework also uses this in "the basement".
However entitity framework helps you to map from database to objects..
With ADO.NET you have to do that yourself.
It depends on how you program it how fast it is..
When you use ADO.NET datatables as "objects". They are a bit slower and memory hungry than plain objects..
正如 Julian de Wit 所说,没有什么比 ADO.NET DataReaders 更快。
ADO.NET 实体框架是旧 ADO.NET 的包装器。
它是纯粹的独立于提供商的 ORM 和 EDL 系统。
它给我们带来了很多过去必须手工制作或“复制和粘贴”的好处。
它带来的另一个好处是完全独立于提供商。
即使您喜欢旧的 ADO.NET 机制,或者像我一样是个恐龙 (:P),您也可以使用
EntityClient
来使用实体框架,例如SqlClient
、MySqlClient
并使用 Entity-Sql 的强大功能,与提供商无关。我知道,使用 ADO.NET,您可以编写数据访问层,并且 DataReaders 等可以是“独立的”,但您可以窃取特定于提供程序的查询。
另一方面,在企业应用程序中,您可能永远不想更改数据提供者。
但随着技术的发展,总会出现新的需求,您可能需要更改数据库模式。
当旧的 ADO.NET 框架发生这种情况时,我们必须重构大量难以维护的代码,无论我们如何重用这些代码。
性能会受到影响,但通过所有这些缓存技术,我们可以克服这个问题。
正如我常说的,“C 很快,Assembly 更快……但我们使用 C#/VB.NET/Java”
As Julian de Wit says nothing is faster than ADO.NET DataReaders.
ADO.NET Entity Framework is a wrapper to the old ADO.NET.
It is pure Provider independent, ORM and EDL System.
It gives us a lot of benefits that we have had to hand craft or "copy & paste" in the past.
Another benefit that comes with it is that is completely Provider independent.
Even if you like the old ADO.NET mechanism or you are a dinosaur like me(:P) you can use the Entity Framework using the
EntityClient
likeSqlClient
,MySqlClient
and use the power of Entity-Sql witch is provider independent.I Know that with ADO.NET you can write a data access Layer and the
DataReaders
etc can be "independent" but you have steal have Queries that are provider specific.On the other hand,in an enterprise application you may never want to change the data provider.
But as the technology grows, always new needs arise and you may want have to alter the database schema.
When it happens with the old ADO.NET Framework we have to refactor alot of code which is less than maintainable, no matter how we reuse the code.
The performance will be affected but with all these cache technologies out there we can overcome this.
As i always say, "The C is fast, the Assembly even more...but we use C#/VB.NET/Java"