entity data framework - 101

I am used to using datasets for my projects in terms of data access. I now set mys开发者_开发知识库elf an easy app to work on in order to learn the entity data framework and how to retrieve & manipulate data.

All the tutorials and samples I have found on the internet are too advanced for me.

Can anyone guide me through on where to start, what are the advantages of this model, In what scenarios should I choose to use entity framework and what are the things (basis) I should now before starting.

My datasets are working fine too. Are there any reasons for me not to stick with that way of accessing data? Or is this something to consider depending on the users of the website (for speed purposes etc.)

Any information - guidance would be appreciated.

Thank you in advance..

The question you're asking ("When should I use an ORM as opposed to DataSets/hardcoded SQL?") is a little too broad to be addressed adequately on a Q&A website. However, here are a couple of the high points:

• ORM's provide safety because they generate classes from the tables in your database (or the other way around, should you choose to go that route) and you perform your in-code interaction on those classes instead of embedding field and table names into your code. This provides you with compile-time safety, ensuring that you don't fat-finger one of those and discover it hidden deep within the recesses of your application six months after it's been deployed.
• ORM's provide a more natural means of accessing related entities (I can do things like 'customer.Orders' or 'order.Customer' in code) rather than either embedding SQL in a string or accessing everything via stored procedures

And a couple of disadvantages

• In all but the simplest operations, ORM-generated SQL is likely to be slower than hand-crafted SQL or stored procedures. You use an ORM for safety and convenience, not for speed.
• It's easy to use features like lazy loading (where related entities are loaded on-demand rather than up front) and incur a performance penalty without realizing it.
• In order to take full advantage of an ORM (meaning relations and using it throughout updates, deletions, and inserts), you generally have to bring back an entire object into memory rather than just a portion.

I agree with all the points Adam Robinson made, but I would add however, the move to an ORM (in my case EF4.0) was all about developer productivity. Previously I did all hand coded classes and data access methods, and carefully crafted stored procs for all data access - and quite frankly the performance could not be beat by just about anything - but all that hand coding requires a lot of time.

I would conservatively estimate that I am cutting most of my development efforts in half using EF4.0 instead of my old methods, and my users have not noticed any perceptible slow down. In the few cases where I do need extra performance, I can still hand coded some data access and/or a stored procedure to get some extra oomph when needed.

So, in answer to your question, there is nothing "wrong" with your way of doing things, but you should go thru the whole process of learning an ORM, and then see if they pros outweigh the cons for you.

The learning curve for ORMs (any ORM) is significant. Don't let the simplistic code generation at the beginning of the process fool you.

If someone knew both ORMs and datasets, I think they would choose the ORM 99% of the time, the advantages are that compelling. ORMs aren't perfect, but they are way better than datasets in almost every scenario.

That said, if datasets are working for you, and the learning curve of ORMs is stumping you, it is completely okay to stick with datasets. I would encourage you to keep hitting the learning curve for ORMs even if it takes years of on and off study (and it might).