2

I am trying to get some advice on what order I should learn about SQL Server, LINQ, and Entity Framework to be able to better work with ASP.NET Webforms and MVC.

From what I've been able to learn so far, many recommend learning LINQ or Entity Framework before learning SQL Server. It also appears that many companies are looking for people with knowledge in LINQ-to-SQL and Entity Framework without mentioning SQL Server. However, my understanding is that LINQ-to-SQL and Entity Framework translate code into SQL Server queries, making this a poor approach.

Is there a correct or best order in which to learn these technologies?

Improve this question
2
  • 3
    I'm not sure why the flags and close votes. There's a difference between asking what to learn or if learning something is a good idea (both of which make for poor questions) and asking about an order in which to learn a fixed set of related technologies to build upon existing knowledge efficiently.
    – Thomas Owens ♦
    Oct 29, 2012 at 14:34
  • Learn all of them together. They complement each other and you need to know all three.
    – usr
    Jun 6, 2016 at 11:20

4 Answers 4

Reset to default
6

You are correct - you should learn SQL Server either before or along with the other skills. I've seen plenty of entity-framework queries blow up because SQL Server couldn't handle the SQL that was passed to it.

I believe we should use the right tool for any job. Often, SQL Server is the best tool to perform a particular task.

It's true that "he who has a hammer treats everything like a nail". If you only learn LINQ-to-Entities, you'll occasionally use LINQ-to-Entities when you should have used a stored proc on SQL Server.

Improve this answer
3

I'm going to go against the grain and suggest LINQ->EF->SQL Server. Here's why:

  1. LINQ is much more than just writing queries, or converting C#/VB to SQL. It's also a door to functional programming (.Select() => Map(), .Aggregate() = fold(), .Where() = filter() .SelectMany() = bind()) and thus applies to many more domains and problems outside of just getting data from some source. SQL itself is more of a one-trick-pony. It's a huge, important, trick but it's still just getting data from a database. (I'm not saying that you can't write full fledged software mostly in SQL, or write incredibly complex SQL queries, I'm arguing that it's usually stupid and you'd be better suited learning to write better LINQ queries instead).
  2. You'll get more done faster. Learning SQL first is more of a "start from the foundations and work your way up" approach, which is a good idea if you're in school, or otherwise have a bunch of time on your hands, but I don't get that impression. You'll only get less from this approach if you duck out early and forgoe learning SQL/SQL Server. Don't do that.
  3. If, and when, SQL Server craps the bed because you've written a horrible LINQ query, you can get help with that query and move on. TBH... although it happens, in my experience, it's much less common than people let on.
  4. Considering that you don't write SQL now, I'm assuming that you're a student or self taught. For now you can continue to lean on DBAs and people who know SQL to tackle the performance problems that require stored procs while you get better at what you're doing now - application code. I think that this instantly improves your quality and usefulness to your/a employer.
  5. SQL Server is a beast. I don't suspect that you're looking to learn it all, but it is truly massive once you get into all that it can do. I can easily see someone getting lost in SQL pretty easily if they have zero experience with declarative languages (that is, you might not know where SQL ends and SQL Server begins).
  6. Neither is LINQ or SQL a subset of the other, but there is an intersection, so knowning one is good help when learning the other. Thus, I don't think that learning either first better helps you learn the other more.

Some will disagree, and I welcome their arguments, but this is what I think.

Improve this answer
3

I think that SQL and LINQ are two different things that you need to learn as a .NET programmer. I also think you can learn them somewhat concurrently, depending on what you know about DB and SQL basics already.

SQL is going to be more portable knowledge that, in addition to new development, you can use on legacy projects and reporting tasks. When there's a lack of DBAs (and there almost always is), you'll probably be called up to generate a quick report for accounting/marketing/etc. with the latest numbers on this or that. Or, you might get handed a legacy VB6 app as your responsibility that has inline SQL. Understanding the SQL will be essential to almost all .NET programming jobs.

LINQ is essential to know if you're going to do something other than legacy (Framework 2.0 or 1.1) .NET programming. Sure, you can write code without using it but this won't be acceptable in organizations that don't have a huge investment in 'ancient' code.

Entity Framework brings SQL and LINQ together. So, once you have a sufficient understanding of both of them you can move forward to EF rather quickly. Remember that EF can be done with straight diagramming of DB ojects, by creating your own objects in code or by a hybrid of these techniques via partial classes. There is tremendous flexibility in it with the 4.0 and 5.0 EF versions.

Improve this answer
1

Learning SQL Server (T-SQL) will give you a deeper understanding of all databases and will allow you to easily pick up concepts from other relational databases (Oracle, MySql, Postgres, etc). In the long run you'll be a more employable person.

A more practical approach might be to learn both. EF's output is T-SQL. Using a tool such as EF Profiler, the raw T-SQL can be viewed and learned.

At the end of the day, T-SQL is much more powerful with data than any ORM (EF, nHibernate or LLBGen)and eventually you'll encounter an problem that can only be solved in the database.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.