Redundant DataContext ? - LINQ to SQL

Question

This seems like a pretty basic question, so bear with me...Say I have two (or many) methods in the same class that need a LINQ to SQL DataContext. Additionally, I am needing the DataContext in other classes as well. Does it make sense to create the new DataContext every time?

Should I be creating this DataContext in a different data access class and then inheriting it on each page? I feel like this is the way it should be done, but I'm still learning LINQ to SQL and just looking for some best practices. Can anyone point me to good examples of this?

Thanks,

Code for reference:

protected void LoadProducts()
{
 StoreDataClassesDataContext db = new StoreDataClassesDataContext();
 var query = from p in db.Products
 select new
 {
 p.ProductID, 
 p.Description,
 p.Price
 };
 dgProducts.DataSource = query;
 dgProducts.DataBind();
}
protected void LoadSales()
{
 StoreDataClassesDataContext db = new StoreDataClassesDataContext();
 var query = from s in db.Sales 
 select new 
 { 
 s.SaleID,
 s.SaleDate,
 s.Total
 };
 dgSales.DataSource = query;
 dgSales.DataBind();
}

• Mathieu Guindon: You should wrap your context instance inside a using block, or manually call Dispose() when you're done with it... or are you wiring up your UI directly to your database? ...
• Mathieu Guindon: BTW code isn't "for reference" on Code Review - code is what gets reviewed, it should be at the core of your post, see our help center. Your question is ok, it's just that you seem to provide the code "for convenience"; know that showing your code is mandatory for your question to be on-topic. Cheers!
• FreeMars: Thanks for the quick reply. The "for reference" comment was probably just bad wording by me. This is code I have but also indicative of the type of code I am seeing in a few different places.

Answer 1

I can't make a thorough review right now, but here's a quick fix that should help you structure things up.

What you have is probably working, but you're mixing-up presentation with data concerns. I don't think these methods should be returning void. Picture this:

protected IEnumerable<SalesInfo> LoadSales()
{
 using (var db = new StoreDataClassesDataContext())
 {
 var result = db.Sales.Select(s => new SalesInfo { 
 SaleId = s.SaleID,
 SaleDate = s.SaleDate,
 Total = s.Total })
 .ToList();
 return result;
 }
}

What you get is a bunch of SalesInfo objects that contain your query results. Bind that to your UI instead.

It's probably normal you're re-creating the context everytime, you want these things to be as short-lived as possible.

• Simon Forsberg: This is so freakin' important that if everyone would do this it would save me a ton of headache at work right now!! Don't modify instance variables when it makes perfect sense to just return an object!!
• FreeMars: I can see how this makes sense. I am definitely mixing data/UI here. I hadn't been using using do to this section from Jon Skeet's C# in Depth. I may (likely) misunderstood when/not it was okay to omit using. After searching around some more on the topic, it seems that even in the right scenario when you don't need the using and its auto dispose() call, you should probably just do it anyway?
• Mathieu Guindon: @FreeMars correct: with your current code if you wrap it with using or call Dispose() I believe you'd get some ObjectDisposedException, because your UI would be fetching the data... but that is bad! Rule of thumb, if it implements IDisposable, do everything you can to call that Dispose() method as soon as possible.