Question

I used to have a WORKING database for my ASP.NET site, up until the point that I’ve learned that using static Database Context objects throughout the app lifetime is a very bad practice.

So, initially, I used to have this:

    public class Database
    {
        MainDBContainer db;
        static Database()
        {
            db = new MainDBContainer();
        }
    }

    internal static SiteUser GetUser(string username)
    {
         return db.SiteUserSet.SingleOrDefault(u => u.Username == username);
    }

And, as you may guess, I’ve always used this static object to access/modify the database. Well, because of what I’ve read everywhere (that the static db context is bad), I decided to change the code to this:

    internal static SiteUser GetUser(string username)
    {
        //notice no static constructor for class.

        using (MainDBContainer db = new MainDBContainer())
        {
            return db.SiteUserSet.SingleOrDefault(u => u.Username == username);
        }
    }

The problem with this code (not particularly “this” very code, but the codes that modify something. by meaning this, I meant that I wrapped every db access with the using keyword just like this one), when db.SaveChanges() is called, it doesn’t throw any exception, but nothing happens too. Within the same context, everything works, but that’s it. NOTHING GETS WRITTEN TO THE ACTUAL SQL DATABASE. Before, I had everything set up and working and as soon as SaveChanges() was called, everything was immediately flushed to the database. My user authentication is even broken (straightforward: client sends username/passwordhash, and if its right server sends a random token, and client uses token with every request): User calls login method and successfully obtains a token, but whenever any other code interacts with the User object, from another context, the token is whatever the DB has before, and SaveChanges in the login method had no effect. It’s the same for all methods, I just gave the Login one as a simple example. Am I missing something? Did I miss something obvious while porting code? Probably yes, but what’s it?

Thanks,
Can.

Answer 1

You’ve moved to a disconnected model. When a context is destroyed, EF no longer knows which objects are associated when you create a new instance on the next CRUD operation. Essentially, you manually have to tell EF about the objects you want to persist, and how to persist them.

For saving, you need to call AddObject on the context.

For updating, you call AttachTo and then ChangeObjectState or SetModifiedProperty on ObjectStateManager. (Note: this is only for completely disconnected objects: if you load an object and then make changes — something you might do if you’re doing row-level versioning — EF already knows what to do because it has a built-in change-tracking mechanism, but only while the object is connected.)

For delete, you call AttachTo and then DeleteObject.