ASP.NET Hosting

Why LINQ will succeed

In the official Linq forum, Joe Albahari presents the reasons why he thinks Linq will succeed:
  1. LINQ syntax beats SQL syntax. SQL is flawed in that queries become exponentially difficult to write as their complexity grows. LINQ scales much better in this regard. Once you get used to it, it's hard to go back.
  2. Database queries are easily composable. You can conditionally add an ORDER BY or WHERE predicate without discovering at run-time that a certain string combination generates a syntax error.
  3. More bugs are picked up at compile-time.
  4. Parameterization is automatic and type-safe.
  5. LINQ queries can directly populate an object hierarchy.
  6. LINQ to SQL provides a model for provider independence that might really work.
  7. LINQ significantly cuts plumbing code and clutter. Without sweeping stuff under the carpet, like Workflow or Datasets. This is a credit to the design team.
  8. C# hasn't suffered in the process (in fact, it's gained).
There are some bugs in the PDC – also some obstacles to implementing MetaModel and IDbContext without reverse engineering, but nothing unfixable. Looking forward to the release!
I agree. Great summary.

Cross-posted from http://linqinaction.net

25 Comments

  • it doesn't deserve to succeed it is not a solution for anything in real world development - like most of MS new items it doesn't support n tier development and allows the quick and dirty brigade to produce more garbage apps

  • 1. What is the Fate of this in nTire Enterprise applications?

    2. Why would anybody wants to Compile thier code for a DB "Logic" Change when the columns are same.

    3. How do you see Backend developer and front developer work in a team with this approach?

  • LINQ sucks. It's just another example of MS trying to tie developers into the MS way.

  • > LINQ sucks. It's just another example of MS trying to tie developers into the MS way.

    Great argumentation. I'm stunned by your demonstration.

  • The LINQ syntax is extremely odd and hard to learn. It is almost painful for developers with extensive realational database and SQL experience.

    A well trained developer who knows SQL techniques specific to a particular database will always beat this out.

    The more patterned they can make SQL query generation, the more they can have GUI based designers do this. The more they do that, the less they need developers. A person with an MBA could write an application. Yippee!!!

    What practical purpose does LINQ solve?

  • Telling me a hag looks pretty is about as convincing as about drinking several beers and wanting to date your mom. Thanks, but no cigar, LINQ still sucks.

  • > Thanks, but no cigar, LINQ still sucks

    Again, great argumentation! I'm sure everybody understands why you hate LINQ, thanks to your very detailed explanation...

  • No explanation needed, as of today, LINQ doesn't suck per say, but is definitely not a really good option in a business driven application. I'd rather stick with code generation in which bugs are able to be controlled by me the developer, versus a specific framework that still needs a lot of work if it's going to stay around.

    The biggest point I'll make is the one you specifically stated yourself: "There are some bugs in the PDC"

  • > The biggest point I'll make is the one you specifically stated yourself: "There are some bugs in the PDC"

    This was about a preview release from 2006! Things have been improved a lot since then. We are now in 2009, with the official release from November 2007 and a service pack from August 2008.

  • Any issues you see now? You still have people out there today who are anti-LINQ.

  • The problem is, was, and always shall be that applications manage complexity. Whether an application uses datasets, sql providers, result sets, data tables, sql queries, stored procedures, or gee whizzer bang up gui code generators, not a single piece of the aforementioned technology makes that complexity any easier or harder.

    If you understand how and more importantly, when to user a three layer architecture or other paradigm and you understand how to implement it using technology that *you* understand then you can rapidly develop applications.

    LINQ is just another way to do the same things we've done for years. It doesn't simplify any of the complexity of those applications. It doesn't speed up development and it certainly doesn't make it any easier to reason about complex topics. In fact, if anything, it adds an extra layer of abstraction that only makes it harder to develop software. I don't think it's going to catch on.

  • > I don't think it's going to catch on.

    It already did. And mostly because it's not just a database thing. LINQ is not just LINQ to SQL. It works well with other data sources, such as XML or in-memory objects collections.
    I agree that LINQ doesn't really help in the process of designing applications, but it helps with simplifying source code by making it terser and more expressive.

    Even if you don't believe in LINQ to SQL, you still should investigate LINQ. And if you believe that LINQ shouldn't be used for data access, then you should take a look at how it's used for good in object-relational mappers such as LLBLGen Pro, Genome or NHibernate.

  • LINQ is a joke. its one of those MS ideas that will fade into the sunset.

  • I believe LINQ has caught on, and will continue to have a place in our ever growing arsenal of tools. The one thing I do question is when to use this technology. I have a lot of experience writing TSQL and ADO.NET, so I initially questioned this technology's relevance. After researching and using LINQ I have come to a conclusion, and please correct me if I'm totally of base. LINQ is best used in situations where you need to develop a solution quickly when you don't have strict requirements on performance. Instead of taking a week to write an app you can have it done in a couple of days. I have found LINQ useful when I get some small freelance projects for a small ecommerce site or business app.

    Anyway, this is what I understand up to this point. Am I off base?

  • Julio, with this reasoning, you can't be wrong. LINQ to SQL (I guess that's what you're writing about) can be very efficient for small and quick projects. This is especially true with projects based on a simple relational model (mostly when one table equals one class).

    Now, I would like to stress once more that LINQ is not just LINQ to SQL. I hope someday everybody will get that clear.
    You can use LINQ to Objects, LINQ to XML and other flavors of LINQ for your big and critical projects. They are adapted to any kinds and sizes of projects.

    Even with databases, you'll gain an advantage by using LINQ on big projects. This may not be by using LINQ to SQL, but it can be with LINQ to Entities, for example. LINQ to Entities is just one way to query data with the ADO.NET Entity Framework. When there is an advantage if you use LINQ, you'll use LINQ to Entities. In other cases, you'll use eSQL or other ways provided by Entity Framework.
    The same applies with other object-relational mapping tools that offer support for LINQ.

    It's sad that people still see LINQ as just LINQ to SQL (Microsoft is to blame for this). LINQ can be used for any project. Make yourself a favor and learn about all that LINQ has to offer. A good book can help you for this. LINQ in Action, maybe ;-)

  • With MSFT dropping Linq to SQL, and leaving devs with the alternative of a problematic Linq to Entities (ie: very stunted stored proc support), ... it's frustrating.

    I'm still trying to "grok" Linq, and understand it.

    When database queries become very complicated, using Linq would make it even more difficult to debug & troubleshoot queries. And stored procs should be the way to go. It would add a layer of complexity and obscuration of the inner workings -- when it comes to troubleshooting complex functionality requirements.

    The more I learn, the more it makes me want to drop MSFT dev altogether and finally jump ship to python/django or some other open source alternative.

    --Or at least pretend Linq hasn't happened and stick with Datasets and table adapters.

    I'd be happy if MSFT went ahead to improve and refine datasets & table adapters.

  • LINQ will succeed for use in I think anything but SQL for now.  Lets say I want to search an array or something or some XML, Great!, but not for SQL. Deployment is difficult with linq when you have to deploy a client application and change the connection information.  Also database updates a lot of times also require a reinstall of the application where a good plan using stored procedures and readers etc... gives a lot more flexibility.  

  • "LINQ syntax beats SQL syntax. SQL is flawed in that queries become exponentially difficult to write as their complexity grows. LINQ scales much better in this regard. Once you get used to it, it's hard to go back."

    It's not true for a decent t-sql programmer. T-Sql is beautiful if you know how to write it properly. Unfortunately, most Linq (to Sql) lovers are bad t-sql programmers. Once you know how to properly code T-SQL you won't want to do it in any other way.

    Besides, a lot of complications of deployment and testing are caused by putting sql code outside of database. Recompiling code means "regression-test", "staging", "deployment", in some cases, you have to go through that dreadful, painful long, long process to get a tiny bit done.

    Please, if you want to keep your job, just say NO to "Linq to SQL".





  • Well said Jiang. I was trying to find the way to say what I was thinking. In my evolution as a developer, I have found myself moving toward T-SQL and Data tier development for the reasons you cited. I started using an almost pure VS development style and after 12 years have been migrating my thoughts on architecture to data tier as much as possible. I find that code environment should not be used to perform complex data tasks.

  • What problem does LINQ solve?. If you're really writing adhoc TSQL queries in your .NET code is syntax really the problem? What developer using SP's is overly concerned with the number of lines of .NET code needed to execute the SP? The real problem is the developer that fails/refuses to master their programming domain. So many of the esoteric skills associated with data programming are actually quite routine to the skilled data professional. Likewise, .NET programmers with a limited skill set will be unaware of the data manipulation features already available to them. Furthermore, DBA != .NET developer and .NET developer != DBA therefore .NET coders should not be pressured into coding databases without proper training/support simply because they are 'programmers' in general or had a db course in college. Linq will only make mediocre programmers more profoundly mediocre by obscuring the evidence that they do not understand the principles upon which Linq is built. A developer should and must train, study, and research daily in his/her domain(s) to be considered a professional. There are no professionals that NEED Linq only intermediate programmers (TSQL & .NET) that need to become professionals.

  • "Unfortunately, most Linq (to Sql) lovers are bad t-sql programmers."

    LOL, perfect. Again with MS catering to the lazy. Why this fascination with letting people code who have no business doing any coding??

  • I just gave up! Unlike most developers, I know SQL. I know it really well. I just spent HOURS trying to do a nest left outer join in LINQ and I finally gave up. O would have taken me 2 minutes to create such a simple query in SQL, but LINQ just can't deal with the concepts of nulls.

    Unlike most developers, I have to actually get stuff done and I no longer have time to mess with an obtuse cluster f**k of a language only Anders Hejlsberg can understand!

    The reason 90% of the world uses SQL is because it makes sense. LINQ does not!

  • Usually I really dig the "new stuff" and "the evolution" of our craft. (Coding)

    But this time, with LINQ, I really hate it. I'm so pist. This is the 3rd time I've approached and abandoned the Linq to SQL, LINQ ro Entities thing. Every book I buy always has the simple: Customer / Orders kindergarten stuff and it's still so verbose and brittle. Making any changes to the backend jacks the whole thing.

    EARTH TO MICROSOFT... LINQ SUCKS. IT'S FAR TOO COMPLICATED AND VERBOSE FOR THE REAL WORLD.

    OINK!OINK!



  • LINQ give you another option. The more options and tools you have, the better.

    As fabrice said, LINQ isnt just LINQ to SQL, there are a lot of flavors out there. just check DB40, an OODB with can use LINQ to compile into another kind of query.

    LINQ can help you improve performance using PLINQ, a parallel linq extension for the .Net 4.0, and it can reduce several lines of code thanks to the rest of Linq extensions, like, OrderBy, Sort, Where, etc. I hope u guys still do your data manipulation by hand ! HAHA cuz i dont! I dont like to reinvent the wheel!

    Best Regards!

  • Hey, can someone give me an example to retrieve all rows in the left side table that their corresponding rows are NULL in the right side table using LINQ To DataSet? Use an ID as the join key.

Comments have been disabled for this content.