Should I Learn "Raw" ADO.Net Before Learning Linq or Entity Framework?

Question

When I first started learning how to do Classic ASP, VBscript, and HTML someone told me to go out and purchase Dreamweaver because "it would make life easy" so I did that and it got me my first profesional job. The issue was when the HTML, VBScript, and Classic ASP started to have issues, I had no idea how to fix it and stayed at work many late nights trying to figure what I consider simple issues now, but obviously were not at simple to me at the time (lots of stress).

With that said, I need to start learning about data access strategies in .NET and I don't want to go through that again. Should I learn raw ADO.NET (by "raw" I mean not an ORM or Linq, but DataAdapters and Readers) and then Linq or an ORM or can I just jump right into Linq/ORM stuff? I'm not looking for comparisons between anything, I'm looking for into what would be best for me as a developer long-term. Thanks.

Answer 1

Not required as such to learn traditional ADO.Net techniques to move to linq data access / entity framework. but in order to get a strong hold, i would suggest you to learn that. Because there can be times for you to debug a data provider problem for which you might need a base.

Direct jump may help you to get job done faster for now, but will not help to go miles...

Answer 2

Depends on how you define 'learning'.

I 'm taking it for granted that what you actually want to use for the job long term is LINQ and EF. Having prior experience with ADO.Net won't give you any help there, as the usage model is too different.

On the other hand, it's useful to have an idea of what happens behind the scenes (especially regarding how queries and DataReaders map to actual open database connections).

I 'd recommend taking a look at the API on MSDN and maybe reading some examples there, but no more. That shouldn't take too much time and it will give you a feel for the usage model. If you later find yourself face to face with ADO.Net somehow, you can always go back for more.

Answer 3

I think you should. Having a basic look at it will not cost a lot of time. But understanding Connections, Commands, Adapters and Readers will help you to get rid of mistakes quicker. Moreover, I'm sure you sometimes can't work with Entity Framework for a problem, so you need plain ASP.NET.

Cheers, Matthias

Answer 4

Its always better for a developer to know how basics and fundamentals work.

I dont see any harm in starting to learn ADO.NET first. Understand of datareader and disconnected datasets and stuff and then move on to more newer feature such as LINQ.

Answer 5

You don't need to learn about DataAdapters and Readers as this knowledge is not transferable to working with ORMs.

More useful would be to try looking at some complex queries, and running them in a tool such as SQL Server Query Analyser. This will show where the queries take time, and will help you to optimise your LINQ queries by understanding what happens under the hood.

It's also good practice to run SQL Profiler on your LINQ queries.

Answer 6

You should know about database basics: transactions (very important), relational structures, constraints etc. I think that you don't need to know ADO specific stuff like DataAdapters.

Answer 7

It helps to understand the layers below an abstraction because of the law of leaky abstractions. That doesn't mean that you need to go out and master ADO.NET, but understanding the layers below the ORM will help you when problems inevitably arise.

Answer 8

Don't bother with the DataAdapters and Readers. They're as much as an abstraction as LINQ. If you know SQL relatively well, you're all set. Just try and understand what types of queries are being executed by the underlying technology, so you know when you need to drop to raw SQL to improve something.