0

I am working on implementing a repository and unit of work pattern; but instead of putting my unit of work in the controller and having business logic in the controller I am implementing a request/handler to divide this logic. Is there any downside to splitting the unit of work and having my controllers access through the request/handler? See code example below:

Generic Repo:

public class GenericRepository<TEntity> where TEntity : class
    {
        internal MyContext context;
        internal DbSet<TEntity> dbSet;

        public GenericRepository(MyContext context)
        {
            this.context = context;
            this.dbSet = context.Set<TEntity>();
        }

        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();
            }
        }

        public virtual TEntity GetById(object id)
        {
            return dbSet.Find(id);
        }

The Unit of Work:

 public class UnitOfWork : IDisposable
    {
        private MyContext context = new MyContext();
        private GenericRepository<User> userRepository;

        public GenericRepository<User> UserRepository
        {
            get
            {
                if (this.userRepository == null)
                {
                    this.userRepository = new GenericRepository<User>(context);
                }
             return userRepository;
            }
        }

Then I am creating a request/handler for each of my models and instantiating Unit of Work in there:

  public class UserRequest
    {
        private UnitOfWork unitOfWork = new UnitOfWork();

        public User GetById(int id)
        {   //more business logic would go here in the handlers...
            return unitOfWork.UserRepository.GetById(id);
        }

The controller will access the request/handlers:

 public class HomeController : Controller
    {
        private UserRequest userRequest = new UserRequest();

        public ActionResult Index()
        {
            var user = userRequest.GetById(1);

            ViewBag.UserEmail = user.Email;

            return View();
        }

Note: there will be multiple request/handlers that are instantiating the unit of work instance. Could this cause issues since unit of work's purpose is to keep the context to one instance?

Thank you in advance for your feedback!

  • 2
    Why do you feel the need to do all this extra abstraction? Even Microsoft no longer recommends Unit of work and generic repositories with Entity Framework anymore. http://www.asp.net/mvc/overview/getting-started/getting-started-with-ef-using-mvc/advanced-entity-framework-scenarios-for-an-mvc-web-application#repo – Erik Funkenbusch Jan 16 '15 at 04:54
  • I'm taking the time to go down the path from the link and see no clear example of implementing EF without the repo/unit of work pattern. Do you pass the context directly into the request/handler that in return would be instantiated in the controller? Does this give you multiple instantiated context? Thank you for clarification! – Michael Freeman Jan 16 '15 at 14:17
  • That's really a different question... And you should probably ask it as a different question. – Erik Funkenbusch Jan 16 '15 at 15:30

0 Answers0