Haven't jumped on the Linq bandwagon, what are your reasons for not using linq?

Question

Hi,

I seem to be in the minority, but to be honest I am not comfortable with linq and don't see any benefits in my personal development (not to say there are no benefits, just a personal opinion based on my situation).

I build web applications (.net, .net mvc) and I love having part of my data layer in stored procedures. One thing I love about sprocs is that I can generate the entire db to script, then scan my queries, readable queries I might add, at a high level.

For those of you who don't like linq, what is your reason? Is it just lack of knowledge/learning curve or is there a business case for not using it?

Answer 1

There was a helpful discussion here recently about whether to use LINQ or stored procedures, which includes the advantages and disadvantages of each approach.

And some people have concerns about the future of LINQ to SQL.

Is LINQ to SQL DOA?

Has Microsoft really killed LINQ to SQL?

Answer 2

I hate SQL, and have been using LINQ for the last year or so. I definitely prefer LINQ syntax over SQL syntax anyday.

Answer 3

I actually do use Linq, but not for querying SQL. I use it as a really easy way of querying datatables to, for example, find the highest value in a datatable. Previously I would have used a for-loop for this code, but Linq makes it neater, and clearer as to my intent.

Once you realise that Linq is a general-purpose .NET query language, it's power and utility becomes much clearer.

Answer 4

Using of stored procedure or Linq is your choice of course, both have pros and cons.

Basically as a pros for Linq you don't need to spend your time to create your data layer but in stored procedures you have to write a new stored procedure for each entity(maybe you could have a generic solution for that "stored procedure hell" but i think that would be complex to maintain). And I also think that the maintenance of a stored procedure is more complex than Linq(of course after you spent a little time with Linq.)

But as expected, getting data by using stored procedures is faster than using Linq.

And after the Oracle and other database support to the Linq will occur; if you still use stored procedure and you have to change your database or you want to support another database then you need to write Oracle and other database version of these stored procedures and I think then that will be a real hell, but not in Linq.

Answer 5

I'm using LINQ for queries on arrays or generic lists. It's very easy to read and saves me a lot of typing for foreach-loops even if I go through multiple lists.

Answer 6

I'm currently creating software for Windows XP Embedded. I did a few spikes using linq and had to take it out because currently XP embedded only supports .Net 3.0 or lower, bummer. It wasn't much work but my code looked a lot better with Linq than without.

I havn't used Linq to SQL yet. I did try out a Linq to NHibernate beta and when that's ready it's definately the way to go for me when I have to do something with a database again.

Answer 7

So do you never do any handling of collections in your C# code? Finding the maximum value within a collection, or filtering, or grouping etc? I know I do these fairly often. LINQ lets me do this in a very readable, declarative manner (more readable than SQL, IMO - the order of the query is more logical).

Likewise querying XML with LINQ to XML, datasets with LINQ to DataSet etc. Oh, and not to forget parallelisation with PLINQ.

There are lots of reasons to love LINQ :)

Answer 8

I like LINQ. Its easy to read and write. I dont have to worry about my sql query optimization. Its a deferred operation which makes it more cooler. I can return IQueryable which is awesome.

Answer 9

I haven't bothered with LINQ yet as I haven't had any real need to.

Over the years I've learned to 'Learn-On-Demand' - new techs come and go so fast that you can waste a lot of time studying the latest trends, just for it to vanish the following year.

Not suggesting that LINQ will, as it seems to have had a good uptake, but I don't lose sleep over coding things 'the old way' as long as my design is sound.

Answer 10

The company I work for has one business case for not using Linq (to SQL):

They like stored procedures because they can be changed after deployment without the need for recompiling, reinstalling, etc.

Personally I don't really like this argument. Because so many people can (and do) make changes to sps at customer sites it can be very difficult to provide effective support.

Linq is a very good technology which makes a lot of tasks in .net very easy and efficient (dev time wise) to achieve. Also, Linq to SQL does provides a very nice mechanism for calling stored procedures.

Answer 11

Right now, lack of knowledge/learning curve (lack of time) is the problem.

Answer 12

The original poster is confusing Linq (lambda expressions for queries) with DLinq(Linq for lightweight databases) cause they are used almost synonymously by the community.

You can use Linq with any collections and use Sql like syntax on it. Its pretty neat.

And yes, you can execute stored procedures using DLinq. See link below

http://weblogs.asp.net/scottgu/archive/2007/08/23/linq-to-sql-part-7-updating-our-database-using-stored-procedures.aspx

-RVZ

Answer 13

We haven't been able to use Linq yet because we're still on 2.0, and haven't been allowed to upgrade to a newer version.

Answer 14

I would prefer to use SQL for querying databases directly (through stored procedures) and then use LINQ to do extra stuff to the data, for example grouping.