views:

185

answers:

3

I've once heard from some developers that L2S is not scalable. I'm not sure that I fully understand what that means. I guess that it has something to do with the layers in your app (provided your app is a layered one). Can someone please shed some light on this subject?

Thanks, Avi

+1  A: 

This is more of a functional scalability. If you look at your LINQ generated domain objects you'll notice a lot of bloat, which may become unnecessary if you were to move to another persistence framework such as NHibernate. One options is to roll out your own domain layer which is more abstract and map your generated domain to the abstract one. Keeping your domain layer 'bloat-free' allows you to reuse it with different persistence frameworks. L2S isn't very good at it. Other things may include performance, but i thought this was improved in later versions?

Sergey
Thanks for the prompt reply.So if i understand correctly, what L2S essentially does is link your domain layer to the data access layer, right? Well, that does sound bad, but is it a scalability issue, or a maintenance issue?One more thing that isn't really clear to me is that you say that there are two domain layers, one that is written by developers and one that is generated. I've never heard of two domain layers before. Is the generated domain created by a code generator? And then mapped to the other domain layer? i still don't get this concept.Thank you very much
Avi Shilon
It's a functional scalability, if anything. L2S has an entity generator which creates the domain/entity layer based your database schema. The domain model you're going to get out of it is tightly coupled to L2S. If you want to be able to port to a different persistence framework at a later date, you may be interested in creating an abstract domain model. However, you will have to map your L2S entities to your abstract domain entities (and back) every time you want to retrieve or persist data, which is an extra overhead. And if your applications is extensible, you can imagine the pain here.
Sergey
This is not an issue, for most projects. Not everyone designs like this. I'm just a purist :)
Sergey
A: 

Even if your collections are small, the SQL generated by a code generator is never going to be as optimized as hand-coded SQL, particularly if getting a good execution plan is highly dependent on picking the right indexes.

Assuming you hand-code these cases and use SPs, in cases where data is very large, you are going to need a lot of tricks to have efficient memory usage regardless of whether your database engine can help you or not.

But every abstraction has limits.

Cade Roux
+2  A: 

I think it scales reasonably well, taking in account that Stack Overflow uses it and it is not a small site.

Konamiman
Interesting indeed...But they might have found some ways to overcome its limitations i guess.
Avi Shilon