Should use Linq or Not? RRS feed

  • General discussion

  • I am designing my project architecture. In our team debate in on whether to use Linq or Not.

    I surf on Google about the linq i found this link which has given the brief advantages and disadvantages of linq.

    There are 3 critical point from our project point of view.

    1. DBML concurrency issues
    2. Small data sets will take longer to build the query than execute
    3. joins are very slow

    All these are Linq related issue which are critical one according to my project requirement as my project is quite big. So performance is very important key factor.

    Can we solve these linq Issues?? If yes How to solve it?

    What is the best approach??? Or should i go with n-Tier architecture?

    Tuesday, December 11, 2012 5:47 AM

All replies

  • Of course youshould use LINQ; when it is the right tool for the task at hand. Most of the "disadvantages" listed in your reference are artificial ones, being simply constructed variations of "Don't be silly!".

    • No clear outline for Tiers:
      Only if the project doesn't have a clear outline for tiers. LINQ is no magic bullet, its use must be designed just as the use of any other tool must be.
    • No good way of view permissions:
      here exactly does this matter?
    • Small data sets will take longer to build the query than execute:
      Does anyone think this doesn't matter for small queries on SQL Server? The DB Engine must optimize queries also, though it may have a more sophisticated mechanism for caching plans than LINQ does.
    • There is an overhead for creating queries:
      Yes! Same for SQL queries.
    • When queries are moved from sql to application side, joins are very slow:
      As I said, use the right tool for the job. Of course use server-based queries for data sets "that are significantly smaller than the base data they are constructed from". But if the data being joined is the same size as the resultant data set, who is kidding who? the data has to move to the client regardless.
    • DBML concurrency issues:
      Why is this any different than standard use of ADO? ANY data that is on the client is clearly a snapshot of how data on he server WAS when it was extracted. Again, use the right tool for the job at hand.
    • Hard to understand advance queries using Expressions:
      All technologies have learning curves. Anyone on your team afraid of new technoloiges should be identified quickly , and assigned to a purely maintenance role until they can find themsleves a job elsewhere. You don't need that dead weight hanging around. 

    I will finish off by repeating the quote from Knuth in my signature:
    "Premature optimization is the root of all evil." - Knuth

    Make sensible design decisions. Measure performance. Identify performance bottlenecks. Solve the bottlenecks.
    All other approaches to solving/preventing performance bottlenecks are make-work that will set you to chasing phantoms.

    "Premature optimization is the root of all evil." - Knuth

    If I provoked thought, please click the green arrow

    If I provoked Aha! please click Propose as Answer

    We are here to learn, to share knowledge, and to earn points; all in about equal measure.

    Tuesday, December 11, 2012 10:12 AM
  • I'd also suggest LINQ, cause I think it's more about knowledge how to use it and avoid disadvatages.

    I have a blog posts about best practices TSQL and LINQ to SQL, take a look, maybe it can help you

    Please Mark as Reply and Vote as Helpful if I helped.

    Also please visit my blog

    Tuesday, January 8, 2013 8:28 AM