Best way to handle the DataContext in LINQ to SQL

I've gotten the go-ahead a开发者_Python百科t work to implement LINQ to SQL for a new module in our ASP.NET app. I forget the best way to handle the DataContext required to retrieve objects; should I create it in every method that makes use of it, or have some kind of Utility class to manage it in a different fashion?

For instance, I have a class that ActiveRecord-style retrieves an entity. Should I be using something like:

using (MyAppDataContext context = new MyAppDataContext()) 
{
    // do stuff here...
}

in each of these methods? I've seen this used frequently in the LINQ tutorials but I've also seen a way where there is a Utilities class that has some method that returns the DataContext (GetContext or similar); I forget if the method was just a wrapper around newing one up or if it did some kind of Singleton-type mechanism.

Which would be the better approach?

---

Personally, I use something similar to this:

public class MyClass : MyBaseClass
{
     public void GetData()
     {
          using(DbDataContext db = new DbDataContext())
          {
              // DO STUFF
          }
     }

     public void PerformLogicallyAtomicAction()
     {
          using(DbDataContext db = new DbDataContext())
          {
              // DO STUFF
          }
     }
}

Unless there is any need to hold the data context open longer.

Update

To clarify a little bit more on the reasons why I do this:

1) I don't want an object in memory any longer than I need it

Below is the main reason

2) Tracking Change Data causes stale data in some cases (See 2nd comment on OP)

3) Creating the new object takes 0 time (effectively)

4) By creating it every time I need it, I can change specific LINQ options (EG. ObjectTrackingEnabled (which I frequently turn off)

---

I would use a class / object to contain the Methods you are using for this repository of data. I instance the datacontext with the class and then I can use it to read data and subsequently update it and stay in the same context.

I also use this class to centralize the connection string so that I have consistency across the entire application in accessing this particular data:

public class MyInfoRepository
{
    MyInfoDataContext _dc;
    public MyInfoRepository()
    {
        try
        {
            _dc = new MyInfoDataContext(GetDbConnection());
        }
        catch (Exception ex)
        {
            ExceptionLogger.LogServerException(ex, TraceEventType.Error);
            throw;
        }
    }

    private static string GetDbConnection()
    {
        // if no connection string return empty which will stop processing
        if (ConfigurationManager.ConnectionStrings["MyInfo"] == null)
        {
            throw new ConfigurationErrorsException("No connection string specified.");
        }

        string connection = ConfigurationManager.ConnectionStrings["MyInfo"].ConnectionString;

        return connection;
    }

...

As some of your comments stated, I would not keep this open, but use it for a particular query and update possibly with a using () statement.