6

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.

  • If you don't understand how ADO.NET works, you need to at least read enough to fix stuff when things break. It's probably not important to spend time becoming well-versed in the syntax, because you can always ramp up on that when the time comes, but if you don't have an idea of what you are actually doing with the ORM then there is a good chance you will mess something up at some point. – smartcaveman Mar 17 '11 at 13:43
  • 1
    I suggest posting the question at http://programmers.stackexchange.com/ – Martin Liversage Mar 17 '11 at 13:44

8 Answers8

3

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.

Josh Smeaton
  • 47,939
  • 24
  • 129
  • 164
  • Exactly. If you look at and understand the SQL generated by an ORM you can avoid some of the pitfalls such as Select N+1 problems. Learning DataAdapters isn't going to help you with this at all. – Henrik Mar 17 '11 at 13:49
3

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.

Jon
  • 428,835
  • 81
  • 738
  • 806
2

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.

jason
  • 236,483
  • 35
  • 423
  • 525
1

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.

Lav
  • 1,850
  • 15
  • 17
1

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

Matthias Meid
  • 12,455
  • 7
  • 45
  • 79
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...

CodeMad
  • 950
  • 2
  • 12
  • 30
  • Thanks and the whole "miles" comment is exactly why I asked the question. –  Mar 17 '11 at 14:42
0

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.

Stefan Steinegger
  • 63,782
  • 15
  • 129
  • 193
-1

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.

DaveRead
  • 3,371
  • 1
  • 21
  • 24
  • So if I never look at an adapter or reader, I could still understand what's going on in the ORM or Linq? –  Mar 17 '11 at 14:44