Paul Gielens:ThoughtsService

I find several items on that list of problems pretty irrelevant, if you ask me. Item 3, 4 and 5 for example are noise or wrong. What does #4 mean? Linq to sql doesn't encourage select * queries at all. Item #3, well.. I've written enough about that ;). Item #5: perhaps this goes a bit wrong if you keep the context around forever, but frankly I don't see real problems.

Your #6 point is also noise, sorry :). What does 'isn't a natural fit for enterprise scenarios' mean? is that a consequence from the 1:1 mapping? If so, sorry, but that's BS, as table definitions too are a projection of entity definitions.

Everyone can say 'isn't fit for...' but without arguments it's nothing more than hot-air.

You both don't address why linq to sql is typically not ready for large applications:

1) the designer forces you to have all entities on 1 canvas, and generates the code into 1 codefile. Working with 300 entities or so is a nightmare

2) code generation isn't templated, you can't alter the code generation process to your own liking

3) fetch plans / prefetch paths / hierarchical fetches are poorly implemented and will cause a lot of performance problems because it executes 1 query per node per parent. See my last post about linq to llblgen pro how bad that can get.

4) distributed scenarios are cumbersome to implement as changetracking is implemented inside a central unit-of-work context, which requires the developer to babysit changes in entities.

Anko doesn't really specify arguments with his points, so it's not really useful to comment on them, however point 2 is valid: linq query tuning isn't really possible. This isn't really a problem related to linq to sql but it's a problem related to linq, you need to know, in detail, how a given construct is converted into SQL: will this result in a join, in a derived table, in a subquery in the where targeting a list of constants, or something else?

This is especially bad because the DBA can't assist the developer how to make the query better, as is the case with more lower-level query api's found in many o/r mappers.

Frans,

Seems like you filled in all of the blanks for him :)

I think the answer to this bit: "isn't a natural fit for enterprise scenarios" is pretty obvious.

The core issue, as I see it, is exactly what you covered in your last sentence.  LINQ is a RAD developers dream and perfect for prototyping and small scale applications.  But in a large scale enterprise environment, experienced DBAs are worth their weight in gold when it comes to optimizing storage structures and data retrieval strategies for optimal response times and minimizing hardware load.

Charles: I'm not defending Linq to Sql here, sorry if I gave that impression ;). What I think should be done more is that if people say "it's not ready for enterprise usage", they should back that up, whatever the technology in question: the people who don't see why will only learn if the arguments are given with the statement.

You are right about the DBA's being important, but I don't think it's that disturbing with Linq in general, perhaps it's disturbing with Linq to Sql in particular due to its pretty lame prefetch/hierarchical queries approach. I think when people learn how to write proper queries for given scenario's (i.e. the scenarios people will run into in every app) and learn how to split in-memory logic from db-oriented logic, it's not that much of a burden for servers.

However till then it's indeed something to take into account when using Linq (in general) for database access: cross-join queries are written easily (and you really don't want these, but Linq's syntax sometimes forces you to, as it doesn't have a way to specify a join with a custom set of predicates), queries where it's hard to guess what's running where (in-memory or db) and queries where's hard to guess how it will look like in SQL. Especially multi-aggregate with groupby queries are problematic: it's easy to write 'contains' in a linq query, however it's hard to optimize the complete subquery tree away ;)

I do think it's required though to keep 'Linq' and 'Linq to Sql' separated. 'Linq' as a technology isn't really something to worry about.

Pingback from  LINQ to SQL problems « Freekshow

I would like to address Frans' concerns.

1) The designer does not force you to do anything. You are welcome to drag and drop whatever tables you wish onto several canvases and therefore logically split the database. Not ideal, but then force is a very strong word. Nobody has a gun to your head.

2) Generate your own code with templates. Have a look at CodeSmith. You don't have to use the visual studio designer at all. This also addresses issue 1 in another way. Generating the classes with appropriate attributes is actually quite trivially easy. We do it.

3) Write your own stored procedure and map the results if you wish. Not every tool will always do everything and one needs to use the tools appropriately. Linq is just one of many.

4) That's a can of worms. Good luck. In my opinion one should probably manage your updates more atomically than that. No technology I am aware of will multiplex updates across multiple threads without some work. Maybe I misunderstand you.

#5 Linq dataset caching is a problem. It's not always consistent and needs to be tweaked. You can not always dispose of the data context and assume that this will not affect current users, especially if you have web services deployed. We have so many issues with Linq datasets being cached in our web services.

#1 problem

All the debugging and fighting with auto-generated code you have to do to finally get your .DBML file created isn't worth the time you save hitting the '.' in Intellisense to get to pop through your business object relations.  I thought the stored proc method genration was really nice, but forget about using that with Sql Server CE.

oh,i feel happy when enter here.

how can i use linq like that 'select top 5 * from tb'

he he .

my english is very sad .sorry.

i just buy some jiangyou!

ha ha.

As your concern I would like to say Microsoft prefer their own products first so they introduce direct 1-1 mapping with SQL Server.

Regards