Home/ Questions/Q 3614334
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T22:14:09+00:00

I’ve heard from some that LINQ to SQL is good for lightweight apps. But

  • 0

I’ve heard from some that LINQ to SQL is good for lightweight apps. But then I see LINQ to SQL being used for Stackoverflow, and a bunch of other .coms I know (from interviewing with them).

Ok, so is this true? for an e-commerce site that’s bringing in millions and you’re typically only doing basic CRUDs most the time with the exception of an occasional stored proc for something more complex, is LINQ to SQL complete enough and performance-wise good enough or able to be tweaked enough to run happily on an e-commerce site? I’ve heard that you just need to tweak performance on the DB side when using LINQ to SQL for a better approach.

So there are really 2 questions here:

1) Meaning/scope/definition of a “Lightweight” O/RM solution: What the heck does “lightweight” mean when people say LINQ to SQL is a “lightweight O/RM” and is that true??? If this is so lightweight then why do I see a bunch of huge .coms using it?

Is it good enough to run major .coms (obviously it looks like it is) and what determines what the context of “lightweight” is…it’s such a generic statement.

2) Performance: I’m working on my own .com and researching different O/RMs. I’m not really looking at the Entity Framework (yet), just want to figure out the LINQ to SQL basics here and determine if it will be efficient enough for me. The problem I think is you can’t tweak or control the SQL it generates…

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    When people describe LINQ to SQL as lightweight, I think they mean it is good enough at what it does, but there is a lot of stuff it doesn’t even try to do. I think this is a good thing, because all that extra stuff that other ORMs might try to let you do isn’t really even needed if you’re just willing to make a few sacrifices.

    For example, I think it’s a best practice to try to keep all application data in a single database. This is the kind of thing that LINQ to SQL expects if you want to be able to do Joins and whatnot. However, if you work in some environment with layers of bureaucracy, you might not be able to convince everyone to move legacy data around, or centralize on a single way of doing things. In the end you need a more complicated ORM and you end up with arguably crapper software. That’s just one example of why you might not be able to shape that data as it needs to be.

    So yeah, if big .com’s are willing or able to do things in a consistent manner and follow best practices there is no reason why the ORM can’t be as simple as necessary.

    • 0