Linq Deferred Execution vs Fetching data on a separate thread
-
Thus far (before 3.5) I have been using a separate thread when fetching data from a data source. Especially if (a) it is a substantial amount of data or (b) the SP tends to take a while due to data-processing. This keeps the UI snappy until the data arrives! But now with LinqToSQL and deferred execution, the data is fetched at the last possible moment. Does one abandon either threading or LinqToSQL, or is there a way to integrate them, and if so what would be the best way? I'd really like to hear everyone's thoughts and ideas!
-
Thus far (before 3.5) I have been using a separate thread when fetching data from a data source. Especially if (a) it is a substantial amount of data or (b) the SP tends to take a while due to data-processing. This keeps the UI snappy until the data arrives! But now with LinqToSQL and deferred execution, the data is fetched at the last possible moment. Does one abandon either threading or LinqToSQL, or is there a way to integrate them, and if so what would be the best way? I'd really like to hear everyone's thoughts and ideas!
http://channel9.msdn.com/forums/Coffeehouse/402104-DataContext-Linq-to-SQL-and-Win32-best-practices/[^] The above discussion seems to in the direction of: don't use LinqToSQL for "bigger" production and/or enterprise applications as it is not mature enough yet?
-
Thus far (before 3.5) I have been using a separate thread when fetching data from a data source. Especially if (a) it is a substantial amount of data or (b) the SP tends to take a while due to data-processing. This keeps the UI snappy until the data arrives! But now with LinqToSQL and deferred execution, the data is fetched at the last possible moment. Does one abandon either threading or LinqToSQL, or is there a way to integrate them, and if so what would be the best way? I'd really like to hear everyone's thoughts and ideas!
Deferred execution does not solve the problem that the separate thread solves. If you run a LINQ query on the main thread, the entire query operation will take place on that thread (unless LinqToSql does some funny things behind the scenes). It may just happen at a different point in the code. I have not used LinqToSQL myself, but from what I understand, the query will need to translate to SQL at some point and then you are basically back to where you started before LINQ. Probably you will need to integrate the two. I would keep the threading just the way it is and replace the SQL calls/queries with the appropriate LINQ.
-
Deferred execution does not solve the problem that the separate thread solves. If you run a LINQ query on the main thread, the entire query operation will take place on that thread (unless LinqToSql does some funny things behind the scenes). It may just happen at a different point in the code. I have not used LinqToSQL myself, but from what I understand, the query will need to translate to SQL at some point and then you are basically back to where you started before LINQ. Probably you will need to integrate the two. I would keep the threading just the way it is and replace the SQL calls/queries with the appropriate LINQ.
Thanks for your input Dideon, I agree with you deferred execution doesn't solve the problem threading solves. The problem it creates is that even thought the LINQ query is in the background thread it doesn't execute the call to the database until much later, that is until back in the UI thread (most of the time). As the other article I posted suggests, there are ways to "force" LINQ to execute in the background thread but I don't think that is ideal as it kind of defeats some of the porpose of LINQ. For now I have decided to stay away from LinqToSql for bigger projects. Still using and loving Linq in general though ;)