I've been messing around with LINQ a bit now and I have to admit, it's kinda neat.

What I'm wondering is, what is the benefit of LINQ vs. creating objects that access the database using stored procs via a data access layer?  Once you've got the objects created, anyone can use them without having to query the database themselves so you always know exactly where your data is coming from and how it is being entered back into the database.
With LINQ it almost seems as though the whole push for people to use OOP has suddenly taken a 180.  If I were just making a basic little site that didn't really have to do a whole lot, and I was going to be the only one working on it, then yea, LINQ is a neat and fast way to go but I'm just not seeing the benefit of LINQ vs. custom objects for dealing with your typical medium to large website.

Is there any arguement for me getting rid of what I have and going with LINQ?  Am I missing some vital connection where my custom objects actually do tie in with LINQ somehow and make everything glorious?

 Any insight would be appreciated.

Won't we lose some of the flexibility/power of using sql for a query?

I would be surprised if LINQ will support all the ansi sql language capabilities, not to mention the vendor-specific language extensions. 

Its tough to answer your question, cause alot of the answers are going to be more of personal opinion which turns out to be relative to the person answering the question as opposed to the one asking.  I would suggest rather to go take a look at Jim Wooley's site ThinqLinq and see some of the work he's done with Linq.

http://www.thinqlinq.com/

Dave, you are correct that LINQ (to SQL) does not support all of the ANSI sql keywords, but it does support enough to cover a large percentage of your data access needs. In cases that it is missing some statements or extremly complex queries, you are still able to use Stored Procs and call them as simple function calls in your code. It is important to understand that LINQ has nothing to do with databases. The LINQ to SQL provider which sits on top of LINQ is responsible for working with databases (the SQL server family in particular).

I'm sorry we didn't get a chance to chat at the Raleigh code camp last weekend. Come on over to www.ThinqLinq.com and check out some of the possibilities that you can do with LINQ. Better yet, check out my new book, LINQ in Action.

Jim

Great points Jim,

I think its important not to think of LINQ as a replacement for SQL but as another tool that we have in our pocket.  LINQ to SQL provides a real nice codegeneration for the DAL with in VS. As Jim mentioned above you can take your stored procedures and add them as functions in your code. 

LINQ works with much more than just SQL. 

LINQ to XML provides a great framework for parsing XML documents, as well as creating XML docs.
LINQ to Objects is a great way to create custom objects and query them. 

And there's much more than just those few mentioned.

jwooley:

Dave, you are correct that LINQ (to SQL) does not support all of the ANSI sql keywords, but it does support enough to cover a large percentage of your data access needs. In cases that it is missing some statements or extremly complex queries, you are still able to use Stored Procs and call them as simple function calls in your code. It is important to understand that LINQ has nothing to do with databases. The LINQ to SQL provider which sits on top of LINQ is responsible for working with databases (the SQL server family in particular).

I'm sorry we didn't get a chance to chat at the Raleigh code camp last weekend. Come on over to www.ThinqLinq.com and check out some of the possibilities that you can do with LINQ. Better yet, check out my new book, LINQ in Action.

Jim

Hey Jim!   Seeing as I'm moving to Ethiopia in twelve days, I'll definitely have to limit my "come on overs" to the internet for awhile.  Wish I'd known you lived in Atlanta, I could have begged you for couch space when I got stuck at the airport overnight.  Boy would I ever have been glad to "come on over" then! :)

Jim was good enough to respond to me directly when I submitted through his ThinqLinq web site - much of which has already been added to this post by now.
I actually ended up going out and buying the book he co-authored ("LINQ in Action") and spent a good chunk of the weekend reading through it.

My original questions and perspective were quite naieve.  LINQ is used for a WHOLE lot more than just database access.  LINQ is a very easy to use, powerful tool - without changing a thing about the data access on your site, you can start using it today for accessing in memory objects.

If I had to answer my own question, using LINQ rather than custom objects and a DAL is probably going to be a no-brainer.  Through the use of a DBML file (which is basically drag and drop), LINQ replaces your DAL and objects in one fell swoop.  I was absolutely mistaken in thinking it was a move away from object oriented programming and back to inline SQL - instead, I'm learning that it is a far more effecient means of accessing data.

For anyone looking to learn more, "LINQ in Action" is fantastic.  It is the first Manning publication I've purchased but it will certainly not by my last now.

It's a year and a half later and I'm back in country and doing .Net again.  :)

So, for those of you who bit the bullet on Linq, do you still think it was worth it?

(And Jim, it was nice seeing you at the Raleigh code camp last weekend.  Some things don't change!  :) )

 Dave, it was good to (briefly) see you as well. As for your question, I think you know my answer as to whether LINQ is worth the effort. ;-)

Jim
www.ThinqLinq.com
www.TwitterCom/LinqKinq