ASP.NET MVC - эффективные методы DbContext

Question

Я запускаю новый проект .NET MVC с Entity Framework, и я борюсь с некоторыми проблемами.

1. В моей модели у меня около 150 объектов (сгенерировано из базы данных). Это хорошая идея иметь только один DbContext? Если нет, как я должен делить свои сущности?

2. Если у меня один DbContext, и я создаю переменную класса, которая создает экземпляр объекта контекста базы данных (в контроллере), что происходит с этим DbContext? Создает ли он в памяти отдельное пространство для каждого из моих сущностей? В моем случае, когда у меня 150 объектов, это будет не очень эффективно. Я ошибаюсь?

3. Я буду использовать свой DbContext во многих контроллерах. Это хорошая идея создать MainController (где я создаю новый DbContext), который будет унаследован остальными контроллерами? Потому что это позволяет другим иметь доступ к одному и тому же Контексту.

4. Какова наилучшая практика для утилизации моего DbContext? Я читал, что использовать инъекцию зависимостей является хорошей практикой. Но таким образом мне придется придать контекст каждому из моих контроллеров. Какой способ инъекции зависимости наиболее популярен и используется сейчас?

Настоятельно нужен ваш совет. Это даст мне больше информации для этой части развития.

Answer 1

150 Сущности не огромный DbContext, но он выше размера, где EF начинает проявлять проблемы с производительностью при инициализации первого DbContext. Если вы можете логически отделить свои сущности от областей ответственности (называемых ограниченным контекстом), то вы можете рассмотреть возможность использования более одного DbContext. Кроме того, ваше приложение должно использовать все эти объекты? Если нет, вы можете упростить ситуацию. Также обратите внимание: вам нужно как минимум EF6 эффективно выполнять эту работу, предыдущие версии Entity Framework имели проблемы с несколькими контекстами.

Вы также должны быть осторожны при использовании нескольких контекстов. Многие люди попадают в проблемы, потому что они получают сущность из одного контекста, но затем вызывают изменения сохранения на другом, а затем не понимают, почему их изменения не сохраняются. Или они пытаются добавить сущность, полученную от одного к другому, чего вы не можете сделать. Несколько контекстов усложняют ситуацию, поэтому убедитесь, что вы хотите принять эту сложность, прежде чем разделить ее.

Не беспокойтесь о количестве памяти, которую использует DbContext, если вы правильно распоряжаетесь им. Объем памяти будет минимальным, если вы фактически не загружаете объекты из всех этих таблиц.

Я считаю, что общий базовый контроллер является запахом кода. Обычно это совершенно необязательно, и обычно это становится свалкой для каждого фрагмента кода, который, по вашему мнению, вы хотите разделить, что нарушает Принцип одиночной ответственности. Кроме того, вы не должны делать доступ к данным в своих контроллерах в любом случае. У вас должен быть сервисный уровень определенного уровня или бизнес-уровня, который вызывается на уровень доступа к данным. Правильное разделение ваших проблем является ключевой частью разработки хорошего приложения MVC.

Да, инъекция зависимостей - хорошая практика. Я не уверен, что вы подразумеваете под «должны вводить все мои контроллеры». Весь смысл инъекции зависимостей заключается в том, чтобы вводить ваши зависимости, поэтому концепция «необходимости» делает так, будто вы пытаетесь избежать того, что вы пытаетесь сделать.

Зависимость Инъекция - это принцип. Существует много способов достижения этого принципа, и то, как вы используете, полностью зависит от ваших собственных предпочтений и требований. Мы не можем сказать вам, что «лучше», кроме как убедиться, что вы следуете принципу, а не конкретной технологии.

Answer 2

1. Хорошо, что есть DbContext. Если у вас много, вам просто нужно убедиться, что все сущности, которые вам нужны, существуют в этом контексте. Например, если вы извлекаете Person из базы данных и связанные с ними Address, то оба Person и Address должны существовать в том же DbContext.

   Я не пробовал использовать несколько экземпляров DbContext, но нужно обратить внимание на то, что если вы включаете одну и ту же таблицу в несколько контекстов, вы можете столкнуться с классами с похожими именами или, возможно, с конфликтами. Например, если вы включаете Person в два контекста, каждый контекст будет пытаться создать класс с именем Person.

2. При создании DbContext он будет создавать объекты только для данных, которые вы извлекаете из базы данных. Поэтому, если вы запрашиваете одну строку из таблицы Person, тогда будет создан только один объект Person. Если вы запросите 100 строк, будет создано 100 экземпляров.

3. Есть действительно два варианта. Один, создайте новый экземпляр в каждом действии, выполните свою работу и сохраните его. Или создайте в своем конструкторе DbContext и повторите его использование во всем классе.

4. Это зависит от того, что вы выберете в пункте 3. Если вы передадите его в конструктор, тогда выполните IDisposable и отпустите его там. Если вы создаете новую в каждом действии, то убедитесь, что она удаляется с помощью оператора using.

Для инъекций зависимостей существует ряд опций, руководств и т. Д. О том, как это сделать в ASP.NET MVC. Я лично использую Autofac и связанные с ним расширения MVC и передаю новый экземпляр DbContext в каждый контроллер.

Answer 3

Относительно вопроса dbcontext: Я бы пошел с несколькими dbcontext (ограниченными контекстами).

Одной из проблем с одним большим dbcontext является загрузка и время инициализации, так как оно отображает все объекты, и это увеличивается, когда число ваших сущностей увеличивается в вашем контексте.

Теперь ваш проект должен состоять из модулей и это, где вы можете разделить свой большой dbcontext на небольшие контексты db, которые охватывают все, что каждый отдельный модуль должен работать с базой данных, например, предположим, что ваш проект имеет два модуля (членство и биллинга или финансового) для лица, являющегося клиентом/лицом, вы обнаружите, что когда вы имеете дело с человеком в модуле членства, вам нужны все его данные, но не полная информация о его счетах, а когда вы имеете дело с лицом в модуле биллинга, вы будете нужны все его счета-фактуры, но не его полная личная информация, здесь вы можете создать 2 dbcontexts по одному для каждого модуля с человеческим сущностью, который содержит то, что этот модуль нуждается в человеческом сущности.

Джул Лерман имеет хорошую статью о DbContext с Entity-рамками, которые начинаются с, чтобы получить более подробную информацию о том, что я пытаюсь описать здесь, https://msdn.microsoft.com/en-us/magazine/jj883952.aspx

Надеется, что это помогает