At first I thought LINQ to SQL was going to be as simple as creating a datacontext, adding all tables to it and then linq away. After some work and some research, I have discovered that though that did work a little more thought is required. For one, what happens if the database schema changes, would the datacontext be updated? Second, should I have a global all encompasing datacontext or would there be a performance cost?
Most of the how-to's and chapters in books i have read do not really cover this, they simply explain how to setup a new datacontext and then how to begin "linqing". I did a little research and discovered that the data context does not get updated when you make changes to the database schema.
So what is the right way to do this, what should go where, and when? One article i found on the subject can be found at http://www.west-wind.com/weblog/posts/246222.aspx . This article by Rick Strahl a Microsoft MVP, suggests the a global datacontext be avoided. After reading several articles on the matter I am inclined to go with a datacontext per thread. This relitively easy to implement, and circumvents the issue he discusses with the global data context forcing all users to updates at one time. I still, havent found any discussion as to weather the whole database should be modeled in a single context or if seperate contexts should be created to hold logical groups of tables. Additionally, I have yet to see any real discussion on the issue that happens if the database schema changes.
There is a code camp coming up on 6/7/2007 and I plan to follow the linq track exclusively.
Sunday, May 18, 2008
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment