ADO.NET vs ADO.NET Entity Framework

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..

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 like SqlClient, 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"