57

I'm currently writing a data access layer for an application. The access layer makes extensive use of linq classes to return data. Currently in order to reflect data back to the database I've added a private data context member and a public save method. The code looks something like this:

private DataContext myDb; public static MyClass GetMyClassById(int id) { DataContext db = new DataContext(); MyClass result = (from item in db.MyClasss where item.id == id select item).Single(); result.myDb = db; return result; } public void Save() { db.SubmitChanges(); }

That's a gross over simplification but it gives the general idea. Is there a better way to handle that sort of pattern? Should I be instantiating a new data context every time i want to visit the db?

Improve this question
1
  • 1
    You may want to read about the Repository pattern. A quick example is in one of the videos by Mr. Walther in the mvc video tutorials at asp.net\learn\ Commented Dec 23, 2008 at 19:49

3 Answers 3

Reset to default
70

It actually doesn't matter too much. I asked Matt Warren from the LINQ to SQL team about this a while ago, and here's the reply:

There are a few reasons we implemented IDisposable:

If application logic needs to hold onto an entity beyond when the DataContext is expected to be used or valid you can enforce that contract by calling Dispose. Deferred loaders in that entity will still be referencing the DataContext and will try to use it if any code attempts to navigate the deferred properties. These attempts will fail. Dispose also forces the DataContext to dump its cache of materialized entities so that a single cached entity will not accidentally keep alive all entities materialized through that DataContext, which would otherwise cause what appears to be a memory leak.

The logic that automatically closes the DataContext connection can be tricked into leaving the connection open. The DataContext relies on the application code enumerating all results of a query since getting to the end of a resultset triggers the connection to close. If the application uses IEnumerable's MoveNext method instead of a foreach statement in C# or VB, you can exit the enumeration prematurely. If your application experiences problems with connections not closing and you suspect the automatic closing behavior is not working you can use the Dispose pattern as a work around.

But basically you don't really need to dispose of them in most cases - and that's by design. I personally prefer to do so anyway, as it's easier to follow the rule of "dispose of everything which implements IDisposable" than to remember a load of exceptions to it - but you're unlikely to leak a resource if you do forget to dispose of it.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

I wonder if this answer is applicable for new DbContext class? msdn.microsoft.com/en-us/library/…
@tugberk: No idea, I'm afraid. I wouldn't assume it is.
Given the quoted text I actually arrive at the conclusion that you should always dispose the context as soon as you're done with it, not that it "doesn't matter too much". Because given the choice of: A) wondering if a coder stumbled into either of those 2 expensive gotcha conditions described by Matt Warren, or B) just having a blanket rule to call dispose on IDisposables when done. I find B makes things easier, especially with large teams
18

Treat your datacontext as a resource. And the rule of using resource says

"acquire a resource as late as possible, release it as soon as its safe"

Improve this answer

1 Comment

While treating it as a resource is a good idea, there are situations when you can't Dispose it for deferred loading. That you can leave it without Disposing and not face harsh penalties is very useful, IMO.
5

DataContext is pretty lightweight and is intended for unit of work application as you are using it. I don't think that I would keep the DataContext in my object, however. You might want to look at repository patterns if you aren't going to use the designer generated code to manage your business objects. The repository pattern will allow you to work with your objects detached from the data context, then reattach them before doing updates, etc.

Personally, I'm able to live with the DBML designer generated code for the most part, with partial class implementations for my business and validation logic. I also make the designer-generated data context abstract and inherit from it to allow me to intercept things like stored-procedure and table-valued function methods that are added directly to the data context and apply business logic there.

A pattern that I've been using in ASP.NET MVC is to inject a factory class that creates appropriate data contexts as needed for units of work. Using the factory allows me to mock out the data context reasonably easy by (1) using a wrapper around the existing data context class so that it's mockable (mock the wrapper since DataContext is not easily mockable) and (2) creating Fake/Mock contexts and factories to create them. Being able to create them at will from a factory makes it so that I don't have to keep one around for long periods of time.

Improve this answer

1 Comment

My goal is to set it up so that someone using object only interaction with the database is the Save() method. Is that what the repository pattern does? Do you have a link to some examples of what you mean here?

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.