Linq to SQL DataContext

Trev on Tue, 07 Oct 2008 22:07:56 GMT
I've been doing some work using Linq to SQL and I've come across a few things with the implementation that I disliked. I'm in the process of putting together an article detailing the problems I have with the DataContext class and how I managed to work around them. The article should be up in the next few days so keep an eye out for it!

I'm also going to put up a tutorial on creating an xml mapping source which will allow you to use POCO (plain old clr objects) with Linq to SQL as there are a couple of limitations to using the generated classes which in more advanced applications may cause you problems that you have to code around.

Examples of problems I encountered were:

- You don't get access to the getters and setters, you only get a partial method which is raised prior to the value changing or after the value has changed.

- You don't get access to the source code for the properties so if you want to add attributes to them you are stuffed since the code for the property is in a partial class in the generated class file which gets overwritten every time you add a new class to your DataContext.

- The DataContext does not implement any interfaces which means that all of your source code is tightly coupled to the DataContext, this makes it very difficult to do unit testing as you are always communicating with a database.

1 Comments
seperator

Commentrhencke on Mon, 13 Oct 2008 03:23:26 GMT
    If you need the DataContext to implement an interface, you can do the following: Open the source to your partial DataContext class (the non-designer one), and have it implement whatever interface you want. Since it sits in the non-designer file, it will persist through any changes to your DataContext.
Name  
Website
Comment  
(Website is optional)