Как лучше: сделать собственную оболочку для DbContext или использовать DbContext в контроллере

Ответ на ваш вопрос в первую очередь основан на мнении. Никто не может однозначно сказать «один способ лучше другого», пока не будет дан ответ на множество других вопросов. Каков размер/масштаб/бюджет вашего проекта? Сколько разработчиков будет над этим работать? Будут ли у него только контроллеры MVC (на основе представлений) или также будут контроллеры API (на основе данных)? Если второе, то насколько перекрываются методы действий MVC и API, если таковые имеются? Будут ли у него какие-либо невеб-клиенты, такие как WPF? Как вы планируете тестировать приложение?

Entity Framework — это инструмент уровня доступа к данным (DAL). Контроллеры — это инструменты обработки запросов и ответов HTTP-клиента. Если ваше приложение не является чистым CRUD (что сомнительно), вероятно, вам понадобится какая-то обработка бизнес-логики, которую вам нужно будет выполнять между получением веб-запроса по HTTP и сохранением данных этого запроса в базе данных с помощью EF ( поле X является обязательным, если вы предоставляете данные для поля Y, вы также должны предоставить данные для поля Z и т. д.). Таким образом, если вы используете код EF непосредственно в своих контроллерах, это означает, что логика бизнес-процессов почти наверняка будет присутствовать в контроллерах вместе с ней.

Те из нас, кто имеет приличный опыт разработки нетривиальных приложений с помощью .NET, склонны к мнению, что ни бизнес-логика, ни логика доступа к данным не должны присутствовать в контроллерах из-за определенных трудностей, возникающих при реализации такого дизайна. Например, когда вы помещаете логику веб-/http-запроса и ответа, а также бизнес-логику и логику доступа к данным в контроллер, вам в конечном итоге приходится тестировать все эти аспекты приложения из самих действий контроллера (что является вопиющим нарушением Единого Принцип ответственности, если вы заботитесь о SOLID дизайне). Также предположим, что вы разрабатываете традиционное приложение MVC с контроллерами, которые возвращают представления, а затем решаете, что хотите расширить приложение для других клиентов, таких как iOS/android/WPF/или какой-либо другой клиент, который не понимает ваши представления MVC. Если вы решите внедрить дополнительный набор действий контроллера на основе данных WebAPI, вы будете дублировать бизнес-логику и логику доступа к данным как минимум в двух местах.

Тем не менее, это не означает, что вся бизнес-логика и логика доступа к данным в контроллерах должны быть хуже, чем в альтернативном дизайне. Любое решение, которое вы принимаете при разработке архитектуры веб-приложения, будет иметь преимущества и недостатки. Всегда будут компромиссы, независимо от того, какой маршрут вы выберете. Преимущества хранения всего кода вашего приложения в контроллерах могут включать более низкую стоимость, сложность и, следовательно, время выхода на рынок. Нет смысла перепроектировать сложную архитектуру для очень простых приложений. Как бы то ни было, к сожалению, лично я никогда не имел удовольствия разрабатывать простое приложение, поэтому я придерживаюсь «общего мнения» о том, что сохранение кода для бизнеса и доступа к данным в контроллерах «вероятно» не является хорошим долгосрочным проектным решением.

Если вас действительно интересуют альтернативы, я бы порекомендовал прочитать это две статьи. Они являются хорошим примером того, как можно реализовать шаблон команды и запроса (CQRS), который могут использовать контроллеры. EF реализует как репозиторий, так и шаблоны единиц работы из коробки, но это не обязательно означает, что вам нужно «обернуть» его, чтобы переместить код доступа к данным за пределы ваших контроллеров. Желаем удачи в принятии таких решений для вашего проекта.

public async Task<ActionResult> Index() {
    var user = await query.Execute(new UserById(1));
    return View(user);
}

Обычно я предпочитаю использовать шаблон репозитория вместе с шаблоном UnitOfWork (http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/реализацияшаблоноврепозиторияиединицыработывприложенииasp-net-mvc) - Я создаю экземпляр DbContext в объекте экземпляра UnitOfWork и добавляю этот DbContext в репозитории. После этого я создаю экземпляр UnitOfWork в контроллере, а контроллер ничего не знает о DbContext:

public ActionResult Index()
{
    var user = unitOfWork.UsersRepository.GetById(1); // unitOfWork is dependency injected using Unity or Ninject or some other framework
    return View(user);
}

Это зависит от жизненного цикла вашего приложения.

Если он будет использоваться, расширяться и изменяться в течение много лет, то я бы сказал, что создание оболочки — хороший выбор.

Если это небольшое приложение и, как вы сказали, вы не собираетесь менять EntityFramework на другой ORM, тогда избавьте себя от работа по созданию оболочки и ее использование непосредственно в контроллере.

На это нет однозначного ответа. Все зависит от того, что вы пытаетесь сделать. Если вы собираетесь поддерживать код, я бы предложил использовать оболочку.