CODEWITHSUNDEEP
c#asp.netentity-frameworkado.net
Sanosay
Sanosay

Reputation: 578

Moving from ADO.NET to ADO.NET Entity Framework

I am web developer for nine years now. I love to develop custom CMS and purly hand coded web applications.

I was ok with ADO.NET Data Access model, writting native SQL Queries to the database and calling store procedures via DBCommand.

2 years now i was thinking to move to ADO.NET Entity Framework.

I know there are alot of advantages in terms of productivity but i really don't like/understand the way it work Entity Framework.

In terms of productivity i have create an application that auto generates for me the ADO.NET Code so i don't waste mutch time to code ADO.NET code.

Should i move on Entity Framework?

PS : I am a performance lover.:P

PS 2 :For example, How can i implement a Modified Preorder Tree Traversal to manage hierarchical data (ex : Categories of products) in Entity framework?

PS 3 : I Work with MySql Server

Edit

After a bit of reading, i understand that ADO.NET Entity Framework is wonderful.

It give us alot of benefits that we have 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 micanism 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.

Yes you loose some performance. But with all these cache technologies out there you can overcome this.

As i always say, "The C is fast, the Assembly even more...but we use C#/VB.NET/Java"

Thank you very mutch for the good advices.

Upvotes: 2

Views: 2781

Answers (3)

minnow
minnow

Reputation: 1101

To answer at least one aspect of performance, EF will generate parameterized queries, which is good for performance. Parameterized queries allow the db to store execution plans and the dba to optimize the plans if necessary. Otherwise most queries are treated by the db as totally brand new and thus it creates a new execution plan every time.

Upvotes: 0

Restuta
Restuta

Reputation: 5903

It depends.

ORMs work well when you are forced to persist an object graph to a relational storage. The better option would be to use an Object Database. So:

If your application will benefit from using an Object Database and you are forced to use relational storage, then answer is simple: Yes, you need ORM.

If you already have your data layer strategy and you don't need to spend a lot of time using it and you feel it's fine, then the answer is also simple: You don't need ORM., with one simple "but"...

You can't foresee all advantages/disadvantages until you try. And nobody has your mind and your projects. So the better answer would be: Try it and figure it out yourself.

Upvotes: 2

Erik Funkenbusch
Erik Funkenbusch

Reputation: 93424

The choice of ORM does not change your data model in most cases. You can use the exact same methods that you used to use, but you now use them in code rather than SQL.

In your MPTT example, you would do the same thing, but it would look something like this in the case of a tree of food items, where the root items left value is 1, and right value 20.

var query = from f in food where lft > 1 and rgt < 20 select f.name;

What's more, if you do discover something you can't do very well in the ORM, you can always just use the ORM to call a sproc that does what you need in SQL.

In fact, even if I wasn't using an ORM to map tables, i'd still use it to call my sprocs because it will automatically create all the wrapper code, parameterize the queries, make it all type safe, and reconstitute it into a data transfer object. It saves writing a lot of boilerplate.

Upvotes: 1

Related Questions