Kill The EFUnitOfWork Totally?

Oct 11, 2011 at 2:06 AM

The EFUnitOfWork pretty much serves one real purpose for us - it hands off Save Changes.

It also exposes a context:

        public DbContext DataContext
                if (_dataContext == null)
                    _dataContext = DataContextFactory.GetDataContext();
                return _dataContext;
But outside of a few unit tests, this property isn't used to my knowledge, and it's just calling the Factory anyway.
I would propose we consider folding the Context and Save Changes/Commit into the CookieCutterRepository itself that way no matter what entity we 
DI it with, we have the ability to get the context (we may not need to expose this - thoughts?) and save changes (via the factory storage is what I think is clean).
But the EFUnitOfWork, as cool as it looks to see in code, seems pointless in the was ported in my Code First projects from when I queued up SqlCommands 
and fired them off in a TransactionScope (the good old days), but it never bothered me so I didnt' care to refactor at the time...
But less is more, so what are y'all thinking?