I often have static classes which uses the DataContext somehow, and they all make a new DataContext, but often I already have one instantiated elsewhere, so why not use that?public static bool SignIn(string email, string password, DataContext db = null){    bool disposeDb = false;    if (db == null)    {        disposeDb = true;        db = new DataContext();    }    //Sign In stuff, or any other stuff...    if (disposeDb) db.Dispose();}But is there a cool trick to do this, or am I just coding it wrong?  Or is it ok? UpdateThe DataContext is not expensive to instantiate.  I guess I just leave it be.But here is another example:public static User GetUser(DataContext db = null){    if (HttpContext.Current.Request.Cookies[Id] == null)    {        return null;    }    else    {        bool disposeDb = false;        if (db == null)        {            disposeDb = true;            db = new DataContext();        }        int id = Convert.ToInt32(HttpContext.Current.Request.Cookies[Id].Value);        string cookieKey = HttpContext.Current.Request.Cookies[CookieKey].Value;        User user = db.Users.FirstOrDefault(x => x.Id == id && x.CookieKey == cookieKey);        if (disposeDb) db.Dispose();        return user;    }}This is again nice because if I already have a context, I can provide it, and then I won't have to attach the entity (User) to another context if I want to modify it:User user = MyClass.GetUser(db);user.Email = asdsasd;db.SaveChanges();How can I improve it?  Or is it okay?Update 2The DataContext should only be instantiated once per page request. And here is a neat way to do it, that actually allows me to access it even from static methods.
Instantiating if null
c#;entity framework;asp.net mvc 4;null
I see 2 issues with SignIn method:it is static. It means that you can't unit-test business logic that uses SignIn functionality in isolation, you'll have to hit the database in your tests.DataContext in web applications should usually be instantiated once per web request because in most cases web request represents a unit-of-work, and as such should be covered by a single transaction. If you're using ASP.NET MVC you can move all the logic that deals with DataConext instantiation and calling SaveChanges/Dispose into base controller class, and expose instance of DataContext as a property. That way you business logic will be cleaned from DataContext management, and most likely you won't actually need a separate class with methods like SignIn since the functionality can go right into Controller class.About GetUser method - if this a method is in Controller class, and taking previous bullets into consideration, the code would look like that://MyBaseController exposes DataContext propertypublic class UserController : MyBaseController{    public User GetUser()    {        HttpCookie idCookie = Request.Cookies[Id];        HttpCookie keyCookie = Request.Cookies[CookieKey];        int id;        if (idCookie == null || keyCookie == null || !int.TryParse(idCookie.Value, out id))            return null;        return DataContext.Users.FirstOrDefault(x => x.Id == id && x.CookieKey == keyCookie.Value);    }}