Entity Framework VS pure Ado.Net

Question

By following the naming conventions , you will find it's called : ADO.NET Entity Framework , which means that Entity Framework sits on top of ADO.NET so it can't be faster , It may perform both in equal time , but let's look at EF provides :

• You will no more get stuck with writing queries without any clue about if what you're writing is going to compile or not .
• It makes you rely on C# or your favorite .NET language on writing your own data constraints that you wish to accept from the target user directly inside your model classes .

Finally : EF and LINQ give a lot of power in maintaining your applications later .

There are three different models with the Entity Framework : Model First , Database First and Code First get to know each of 'em .

-The Point about killing performance when remapping is on process , it's because that on the first run , EF loads metadata into memory and that takes time as it builds in-memory representation of model from edmx file.

ADO. Net is an object oriented framework that allows you to interact with database system (SQL, Oracle, etc). Entity framework is a techniques of manipulating data in databases like (collection of queries (inert table name , select * from like this )). it is uses with LINQ.

Entity Framework is not efficient in any case as in most tools or toolboxes designed to achieve 'faster' results.

1. Access to database should be viewed as a separate tier using store procedures as the interface. There is no reason for any application to have more than absolutely require CRUD operations. Less is more principle. Stored procedures are easy to write, secure, maintain and is de facto fastest way. It's easy to write tools to generate desired codes for POCO and DbContext through stored procedures.

2. Application well designed should have a limited numbers of connection strings to database and none of which should be the all mighty God. Using schema to support connection rights.

3. Lazy loading are false statements added to solve a problem that should never exist and introduced with ORM and its plug and play features. Data should only be read when needed. Developers should be responsible to implement this logic base on application context.

4. If your application logic has a problem to maintain states, no tool will help. It will in fact, make it worse by cover up the real problem until it's too late.

5. Database first is the only solution for a well designed application. Civilization realized long time ago the important of solid aqueduct and sewer system. High level code can and will be replaced anytime but data stays. Rewrite an entire application is matter of days if database is well designed.

6. Applications are just glorified database access. Still true in most cases.

This is my conclusion after many years in business applications debugging through codes produced by many different tools or toolboxes. The faster results advertised are not even close to cover the amount of time/energy wasted later trying to clean up the mess. Performance issues are rarely if not ever caused by high demand but the sum of all 'features' added through unusable tools.