Entity Framework - Как мне создать экземпляр моего объекта “Сущности”

Question

Я абсолютный новичок в Entity Framework и ASP.Net MVC, изучив в основном учебные пособия, не имея глубокого понимания ни того, ни другого.(У меня действительно есть опыт работы с .Net 2.0, ADO.Net и WebForms)

Мое нынешнее сомнение проистекает из того, как я создаю экземпляры своих объектов Entities.

В основном я делаю это в своих контроллерах:

public class PostsController : Controller {

    private NorthWindEntities db = new NorthWindEntities();

    public ActionResult Index() {
            // Use the db object here, never explicitly Close/Dispose it
    }
}

Я делаю это так, потому что нашел это в каком-то блоге MSDN, который показался мне достаточно авторитетным, чтобы я предположил, что это правильный способ.
Тем не менее, я чувствую себя довольно непросто по этому поводу.Хотя это экономит мне много кода, я привык делать:

using (NorthWindEntities db = new NorthWindEntities() {
}

В каждом отдельном методе, которому требуется подключение, и если этот метод вызывает другие, которым это понадобится, он передаст им db в качестве параметра.Вот как я делал все с моими объектами подключения до того, как существовал Linq-to-SQL.

Другая вещь, которая меня беспокоит, это то, что NorthWindEntities реализует IDisposable , что по соглашению означает, что я должен вызывать его метод Dispose(), а я этого не делаю.

Что вы думаете по этому поводу?
Правильно ли создавать экземпляр объекта Entities, как я это делаю?Должен ли он заботиться о своих соединениях, открывая и закрывая их для каждого запроса?
Или я должен распоряжаться им явно с помощью предложения using()?

Спасибо!

Answer 1

Сам контроллер реализует IDisposable.Таким образом, вы можете переопределить Dispose и избавиться от всего (например, контекста объекта), что вы инициализируете при создании экземпляра контроллера.

Контроллер живет только до тех пор, пока выполняется один запрос.Таким образом, наличие using внутри действия и наличие одного контекста объекта для всего контроллера - это точно такое же количество контекстов:1.

Большая разница между этими двумя методами заключается в том, что действие будет завершено до того, как представление будет отрисовано.Таким образом, если вы создадите свой ObjectContext в операторе using внутри действия, ObjectContext будет удален до того, как представление будет отрисовано.Так что вам лучше прочитать что-нибудь из контекста, что вам нужно, до завершения действия.Если модель, которую вы передаете представлению, представляет собой некоторый отложенный список, подобный IQueryable, вы удаляете контекст до того, как представление будет визуализировано, вызывая исключение, когда представление пытается перечислить IQueryable.

В отличие от этого, если вы инициализируете ObjectContext при инициализации контроллера (или пишете отложенный код инициализации, вызывающий его инициализацию при выполнении действия) и удаляете ObjectContext в контроллере.Dispose, тогда контекст все еще будет присутствовать при рендеринге представления.В этом случае безопасно передавать IQueryable в представление.Контроллер будет удален вскоре после рендеринга представления.

Наконец, я был бы неосторожен, если бы не указал, что, вероятно, это плохая идея - чтобы ваш контроллер вообще знал о Entity Framework.Рассмотрите возможность использования отдельной сборки для вашей модели и шаблона репозитория, чтобы контроллер взаимодействовал с моделью.Поиск в Google даст довольно много информации по этому вопросу.

Answer 2

Вы приводите здесь хорошую мысль. Как долго должен существовать ObjectContext? Все книги по моделям и практикам (например, книга Дино Эспозито Microsoft-СЕТЕВАЯ архитектура-Приложения) сказать вам, что DataContext не должен жить долго и не должен быть кэширован.

Мне просто было интересно, почему в вашем случае нет класса ControllerBase (я не в курсе реализации MVC, так что потерпите меня), где ObjectContext инициируется один раз для всех контроллеров.Особенно подумайте о Шаблон Карты идентификации, это уже реализовано Entity Framework.Даже если вам нужно вызвать другой контроллер в качестве вашего PostsController, он все равно будет работать с тем же контекстом и также повысит производительность.