0

I am currently changing my asp.net-mvc site to use the unit of work pattern rather than having my controllers access the database context directly, as I've read that it will make testing easier.

I have been following a Microsoft guide and the unit of work class contains the following get method

 public virtual IEnumerable<TEntity> Get(
        Expression<Func<TEntity, bool>> filter = null,
        Func<IQueryable<TEntity>, IOrderedQueryable<TEntity>> orderBy = null,
        string includeProperties = "")
    {
        IQueryable<TEntity> query = dbSet;

        if (filter != null)
        {
            query = query.Where(filter);
        }

        foreach (var includeProperty in includeProperties.Split
            (new char[] { ',' }, StringSplitOptions.RemoveEmptyEntries))
        {
            query = query.Include(includeProperty);
        }

        if (orderBy != null)
        {
            return orderBy(query).ToList();
        }
        else
        {
            return query.ToList();
        }
    }

However I'm unsure of exactly what this method does, especially what can be passed in as parameters. I am new to c# and asp.net-mvc so apologies if this is a stupid question, can anyone explain more clearly how this method works it would be great? I am altering my ManageController currently and I have a method which accesses the db directly and would like to change this but I don't know how to call the unit of work get method correctly to access to find the current user and their orders in my Order table. Any help is really appreciated!

  public ActionResult ViewBookings()
  {
      string currentUserId = User.Identity.GetUserId();
      ApplicationUser currentUser = db.Users.FirstOrDefault(x => x.Id ==   currentUserId);
      List<Order> bookings = (from b in db.Orders where b.user.Id == currentUser.Id select (b)).ToList();           
        ViewBag.Bookings = bookings;
        return View();
    }
mara19
  • 121
  • 1
  • 4
  • 15
  • 1
    The answer from @Bon is basically correct, I think you'd be adding unnecessary complication just for the sake of implementing UoW. Here's a [similar question](http://stackoverflow.com/questions/26055497/entity-framework-6-and-unit-of-work-where-when-is-it-like-transactions-in-a), and the answer suggests adding a service class which handles db access. – markpsmith Feb 16 '16 at 17:46
  • Adding to that, for small projects or prototypes, or MVPs, there is nothing wrong with calling the db straight from your controllers. By the time you're ready to build the full scale implementation you'll have found lots of things you'll be changing anyway. So save the time during your first stage and prototyping and skip adding another layer like a service bus if you can. – Bon Feb 16 '16 at 18:58

1 Answers1

1

Entity Framework already has UoW built in. That is what the SaveChanges and SaveChangesAsync methods are for. It is unnecessary to add anything to it for UoW pattern.

The code you pasted are just queries with conditionally applied filters. Unit of Work pertains to the Create, Update, and Delete portions of CRUD.

If you are wanting to separate your front end from data access, you are looking for CQRS, Command/Query Responsibility Separation. This can be well achieved using a service bus of some kind that the UI consumes to get and modify data on the backend independent of the actual store being used.

Bon
  • 1,083
  • 12
  • 23
  • 1
    For further reading here's good read http://rob.conery.io/2014/03/04/repositories-and-unitofwork-are-not-a-good-idea/ – vendettamit Feb 16 '16 at 18:46