views:

194

answers:

7

I am curious to know why should a Database person learn LINQ. How can it be useful.

+4  A: 

Linq provides "first class" access to your data. Meaning that your queries are now part of the programming language.

Linq provides a common way to access data objects of all kinds. For example, the same syntax that is used to access your database queries can also be used to access lists, arrays, and XML files.

Learning Linq will provide you with a deeper understanding of the programming language. Linq was the driver for all sorts of language innovations, such as extension methods, anonymous types, lambda expressions, expression trees, type inference, and object initializers.

Robert Harvey
I like the 2nd reason best.
JohnB
A: 

Is this a real question? It can't be answered with a code snippet. Most of these discussion type questions get closed quickly.

Kelly French
...probably best expressed as a comment.
Robert Harvey
@Robert Harvey, yes probably best to be a comment, but the content is true
KM
+2  A: 

I think a better question is why would one replace SQL with LINQ when querying a database?

Tundey
type-safe intellisense in Visual Studio, instead of passing your large blobs of text (SQL queries) with no type-checking and no safety whatsoever (blows up only at runtime in production.....)
marc_s
@mark_s: although there are other ways to do this. Strongly-typed datasets for example.
Robert Harvey
Linq is the preferred method for accessing your data through an ORM such as Linq to SQL or the Entity Framework.
Robert Harvey
@Marc_s: You can get intellisense with tools for databases too. So that's not a compelling reason.@Robert: Linq is the preferred method for accessing your data through an ORM such as Linq to SQL? Isn't that like using a word to define itself. Bear in mind, I am not questing Linq itself. I like the idea of writing queries against non-sql data structures. But I don't understand why one would replace SQL with Linq (replace CAML with Linq on the other hand would be great).
Tundey
Linq to SQL generates SQL under the covers and returns IQueryables. So if you have written a repository for your consumers you may have no further need for Linq. I use Linq to build the repository, because it is simple and straightforward to do that against an IQueryable. But you can also pass the IQueryable to your consumers, who can then write further Linq queries against it, all of which execute only when they are needed (AKA lazy loading). See Remus' answer for a more complete explanation of this process.
Robert Harvey
+1  A: 

"Know your enemy" ?

OTOH, out of interest. I'm learning more about XMl, XSLT, XSDs etc because I can see a use for them as a database developer.

gbn
A: 

I think one of the many reasons why one could consider linq it because linq is big productivity boost and huge time saver

Dmitris
+5  A: 

LINQ has one big advantage over most other data access methods: it centers around the 'query expression' metaphor, meaning that queries can be passed around like objects and be altered and modified, all before they are executed (iterated). In practice what that means is that code can be modular and better isolated. The data access repository will return the 'orders' query, then an intermediate filter in the request processing pipeline will decorate this query with a filter, then it gets passed on to a display module that adds sorting and pagination etc. In the end, when its iterated, the expression has totally transformed into very specific SELECT ... WHERE ... ORDER BY ... LIMIT ... (or the other back-end specific pagination like ROW_NUMBER). For application developers, this is priceless and there simply isn't any viable alternative. This is why I believe LINQ is here to stay and won't vanish in 2 years. It is definitely more than just a fad. And I'm specifically referring to LINQ as database access method.

The advantage of manipulating query expression objects alone is enough of a factor to make LINQ a winning bid. Add to this the multiple container types it can manipulate (XML, arrays and collections, objects, SQL) and the uniform interface it exposes over all these disparate technologies, consider the parallel processing changes coming in .Net 4.0 that I'm sure will be integrated transparently into LINQ processing of arrays and collections, and is really no way LINQ will go away. Sure, today it sometimes produces unreadable, poorly performant and undebuggable SQL, and is every dedicated DBA nightmare. It will get better.

Remus Rusanu
lol @ "every dedicated DBA nightmare".
Tundey
Great answer (I had the same question myself) and good to know it "sometimes produces unreadable, poorly performant and undebuggable SQL." :)
JohnB
A: 

This question also prompts me to ask, if LINQ becomes immensely popular, will server side developers know SQL as well as their predecessors did?

Steve
How well do you know assembly?
Bryan Watts