LINQ to SQL Performance & Resources
-
Hey guys, I've been playing with LINQ to SQL and I'm pretty much surprised by the power of LINQ ;) However, I have this question... I'm developing a website having a business project handling all the communication with my (SQL) database. I created several business object which return data from SQL, or create/remove/modify them in the database. The database behind the website is not that large, it contains a few tables let's say 15 and the amount of data isn't scary too but... Does is matter if I create just one large DataContext for my entire database, or is it wise to create several DataContext object of tables related to each other or does that depend on the database size (amount of tables, or amount of data)?? I understand that when developing modules etc. you mey want each module to contain it's own DataContext, but in this case there's only one business object taking care of everything. Thanks for your opinions...
.: I love it when a plan comes together :. http://www.zonderpunt.nl
-
Hey guys, I've been playing with LINQ to SQL and I'm pretty much surprised by the power of LINQ ;) However, I have this question... I'm developing a website having a business project handling all the communication with my (SQL) database. I created several business object which return data from SQL, or create/remove/modify them in the database. The database behind the website is not that large, it contains a few tables let's say 15 and the amount of data isn't scary too but... Does is matter if I create just one large DataContext for my entire database, or is it wise to create several DataContext object of tables related to each other or does that depend on the database size (amount of tables, or amount of data)?? I understand that when developing modules etc. you mey want each module to contain it's own DataContext, but in this case there's only one business object taking care of everything. Thanks for your opinions...
.: I love it when a plan comes together :. http://www.zonderpunt.nl
It doesnt matter how large your datacontext is :)
I am not a perfect programmer,but i have perfect's programmers' habits.
-
It doesnt matter how large your datacontext is :)
I am not a perfect programmer,but i have perfect's programmers' habits.
atarikg wrote:
It doesnt matter how large your datacontext is
Why? I've found that it DOES matter what's in your datacontext. There are a couple of gotchas to do with EntitySet/EntityRefs that you need to deal with if you have mixed datacontexts, and it's better to break the contexts down so that these issues are removed.
Deja View - the feeling that you've seen this post before.
-
Hey guys, I've been playing with LINQ to SQL and I'm pretty much surprised by the power of LINQ ;) However, I have this question... I'm developing a website having a business project handling all the communication with my (SQL) database. I created several business object which return data from SQL, or create/remove/modify them in the database. The database behind the website is not that large, it contains a few tables let's say 15 and the amount of data isn't scary too but... Does is matter if I create just one large DataContext for my entire database, or is it wise to create several DataContext object of tables related to each other or does that depend on the database size (amount of tables, or amount of data)?? I understand that when developing modules etc. you mey want each module to contain it's own DataContext, but in this case there's only one business object taking care of everything. Thanks for your opinions...
.: I love it when a plan comes together :. http://www.zonderpunt.nl
Eduard - I've found there to be a couple of issues with using a large DataContext to do with EntitySet/EntityRef items. You are better decomposing the application to use multiple contexts to avoid these issues. (See this[^] post for details.)
Deja View - the feeling that you've seen this post before.
-
Eduard - I've found there to be a couple of issues with using a large DataContext to do with EntitySet/EntityRef items. You are better decomposing the application to use multiple contexts to avoid these issues. (See this[^] post for details.)
Deja View - the feeling that you've seen this post before.
Pete, The article seems to be just what I was looking for. I think you can say 'isolating' different 'parts' of your database in a separate DataContext is the way to go.. Thanks for your reply!
.: I love it when a plan comes together :. http://www.zonderpunt.nl
-
Pete, The article seems to be just what I was looking for. I think you can say 'isolating' different 'parts' of your database in a separate DataContext is the way to go.. Thanks for your reply!
.: I love it when a plan comes together :. http://www.zonderpunt.nl
Eduard Keilholz wrote:
Thanks for your reply!
No problem. I faced this issue myself a while ago and it caused me a lot of grief looking for the solution. I wouldn't want anyone else to go through the same problems.
Deja View - the feeling that you've seen this post before.