When using, VS2013, Entity Framework 6 and WebAPI 2, is using a generic repository and UoW framework overkill?

Question

I am re-examining my implementation of the generic unit of work and repository framework.

I am using EF6, and VS2013. As such, VS contains WebAPI controller templates that auto-generate WebAPI 2 OData Controller with Actions, using Entity Framework code like this:

// GET odata/UserProjects(5)/WebsiteRequiredKeywords
        [Queryable]
        public IQueryable<WebsiteRequiredKeyword> GetWebsiteRequiredKeywords([FromODataUri] int key)
        {
            return _db.Websites.Where(m => m.WebsiteId == key).SelectMany(m => m.WebsiteRequiredKeywords);
        }

        protected override void Dispose(bool disposing)
        {
            if (disposing)
            {
                _db.Dispose();
            }
            base.Dispose(disposing);
        }

        private bool WebsiteExists(int key)
        { . . .

In looking at the CustomerController class in the sample code - it all looks very familiar to the auto-generated code in the VS2013 template. If I was using the generic framework, I would have to refactor the auto-generated code to make use of the generic repository syntax, modify the constructor, etc. While I'm sure there is a way to modify the template generation process to conform to this generic repository (or add our own template to the VS template) - this amount of work seems to be unnecessary.

The generic scaffolding template uses the same database context. As I understand it, this is synonymous with a unit of work pattern.

I am trying to now find the value in having to perform any of this additional work. While I have successfully used the generic repository and unit of work patterns in previous projects, for new ones, is it just more work than it's worth (as there is some concept duplication b/t EF and this pattern as well)?

-- UPDATE --

With some minor modifications to the auto-generated code, what would I need to do after implementing something like this:

public class ProjectEditorController : ODataController
{
    //private MyDatabaseNameContext db = new MyDatabaseNameContext();  // auto-generated code

    private DbContext _db;

    public ProjectEditorController(DbContext dbContext)
    {
        _db = dbContext;
    }
    . . .

The problem with this code is that now there is no concrete context, and doing things like:

return SingleResult.Create(_db.Websites.Where(website => website.WebsiteId == key));

...will not work, as there is no concrete link between db and the entities, ie. Websites.

In using DI for WebAPI Controllers, you still have to define a repository. Is this a case where if I wanted to inject the dbContext I need to use the generic repo?

In short, is this accurate: If you want to efficiently use dependency injection, then you need a generic repository. Otherwise, you need to define a repository interface for all your EF entities, unless you use the IDependency resolver, as suggested at the end of this article.

Answer 1

Ayende sums it up pretty well here. Don't add abstraction you don't need.