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...

PositiveGuy
  • 46,620
  • 110
  • 305
  • 471
  • Why wouldn't a 'huge .com' use something 'lightweight'? – Andrew Barber Dec 20 '10 at 05:18
  • 2
    @CoffeeAddict: Lightweight in this context means feature poor. LinqToSql is very feature poor compared to Entity Framework, NHibernate, and many other .NET ORMs. One of the biggest risks with using LinqToSql is you may eventually outgrow it and it is expensive to switch ORMs after the initial commitment. – Michael Maddox Dec 20 '10 at 10:52
  • Thanks Michael. I thought that's what it meant. Well for a .com I do not see it being outgrown. I mean I've worked for several .coms and we don't have anything crazy going on other than mostly simple CRUDs most the time. I just worry about the tweak ability which is not there for LINQ performance. – PositiveGuy Dec 22 '10 at 02:42
  • @CoffeeAddicts: do you think you'll ever change your database structure? Then you'll immediately outgrow LINQ to SQL, which always maps one-to-one to the current database implementation. – John Saunders Dec 22 '10 at 02:47
  • @John No I do not think my Database structure will change but you never know. I mean once you create an ecommerce site on a Database or set of Databases it's pretty hard to then just go change the design of your Database because you'd have broken all your code and it would take hours to fix that or modify your source code to work again with the new Database table design. Then on the other hand in addition to this, I can only see CRUDs being the bulk of operations on an ecommerce site...so do I really need EF??? But then LINQ to SQL is direct 1 to 1 which is not really good ORM design. – PositiveGuy Dec 22 '10 at 04:32
  • So in other words LINQ to SQL doesn't really give you DDD (Domain Driven Development) as compared to an ORM like NHibernate or EF where you can truly create Domain objects that differ from your Database structure...LINQ to SQL classes are just another nice way to create a DL that relies on a rigid structure..meaning that it's closely coupled to the design of your database, complete opposite than DDD. So while for my .com I may not need all the bells and whistles of EF or NHibernate I would want it because I want my site to be flexible and abstracted / less coupled to the DB..sound right? – PositiveGuy Dec 22 '10 at 04:35
  • Note: I'm also leaving this thread open still because I want more replies / opinions / experiences – PositiveGuy Dec 22 '10 at 04:38

1 Answers1

2

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.

Blake Taylor
  • 9,217
  • 5
  • 38
  • 41
  • NHibernate may be more complicated to learn and have way too much out of the box than I really need for a .com (I'm trying to determine if my assumption is correct by looking at what that thing can do...which is a LOT). All I'm doing is simple CRUDs, nothing extremely complex in terms of SQL calls...maybe an occasional proc that has a little more than just a CRUD call but that's about all. – PositiveGuy Dec 20 '10 at 05:28
  • I say give LINQ to SQL a try. I think you'll find it does what you need and it really is quite nice to work with. Out of all the ORMs I have worked with it is certainly one of my favorites. If you need to work with stored procs it has means easily to map these to method calls and map the output to objects. – Blake Taylor Dec 20 '10 at 05:34
  • L2S can do more than simple CRUD as well. With the right Lambda expression, you can rock some pretty sophisticated queries with L2S. The next logical step (IMO) is EF. – Chase Florell Dec 20 '10 at 05:40
  • Yes it's very nice to work with as I can see but for a .com I have to make sure it's performance is there. I am reading though that when using LINQ to SQL for a .com (e-commerce), you're gonna have to focus 100% on the database and tweak performance there instead and not rely on LINQ being that performant (leaky due to the select *, etc.). I'm not sure if you can override the select * or what with LINQ but you also cannot tweak the underlying query being constructed so that's another leaky part. – PositiveGuy Dec 20 '10 at 06:09
  • So then EF. Why would I use EF then? I mean where does the Repository pattern and Unit of work come in with LINQ to SQL? Is that EF then? the layer on top of LINQ which is basically the Repo pattern right there and the mapping of your domain objects...right? I guess what I'm saying is EF is an addition to using LINQ to get the mapping ability. – PositiveGuy Dec 20 '10 at 06:11
  • 1
    @CoffeeAddict: EF is a totally different thing than LINQ to SQL. It works at a conceptual level so does not have to map directly to database tables. In .NET 4.0, it permits you to use simple POCO classes for your data objects, as well as the classic EF objects. It's much more powerful, unless you don't use the power, in which case the power doesn't cost you anything. I don't know any good reason to use LINQ to SQL. – John Saunders Dec 22 '10 at 02:56
  • @CoffeeAddict: see http://stackoverflow.com/questions/8676/entity-framework-vs-linq-to-sql among others. – John Saunders Dec 22 '10 at 02:57
  • @John Thanks a lot for clarifying. So I know POCO stands for Plain Old Class Objects. Ok but in the DL, what does this mean, just a class with properties and no more? Represents the tables? – PositiveGuy Dec 22 '10 at 04:27
  • @John a lot of people are using LINQ to SQL. Examples: Redbox, Cengage, Kaplan, and many more. They swear by it. – PositiveGuy Dec 22 '10 at 04:28
  • @CoffeeAddict: a lot of people do a lot of things that are right for them, but not for you. They also do things that are not right for them, perhaps due to misunderstanding, or not asking on StackOverflow. – John Saunders Dec 22 '10 at 18:56
  • I could have sworn I saw something mentioned somewhere through my online research that EF has the ability to work with LINQ to the SQL but maybe I'm smoking something. Anyway, thanks John. – PositiveGuy Dec 23 '10 at 04:34