Может ли слишком много навигационных свойств быть слишком большим

#c# #entity-framework #entity-framework-6

#c# #entity-framework #entity-framework-6

Вопрос:

Если у меня есть объект:

 public class User
{
   public int UserId{get;set;}
}
  

И другой объект:

 public class Role
{
   public int RoleId{get;set}
}
  

Сначала я хочу смоделировать связь с помощью кода EF, поэтому я добавил:

User.cs

 public virtual ICollection<Role> Roles {get;set;}
  

Role.cs

 public virtual User User {get;set;}
  

Это позволяет мне получать роли пользователей, такие как:

 context.Users.Roles.ToList();
  

Но User является основным объектом в базе данных. И он может иметь отношение к 100 таблицам.

Является ли добавление ICollection<T> и User объект наилучшей практикой или это не всегда требуется (как правило, для этого существует какое-то эмпирическое правило)?

Иногда у меня возникает ощущение, что я создаю слишком большие объекты, и мне интересно, влияет ли это на производительность?

Комментарии:

1. Идентификатор роли должен быть в таблице пользователей, в которой этот пользователь играет эту роль

2. Полностью зависит от данных, которые вы моделируете

Ответ №1:

Вы правы, полагая, что перетаскивание 100 связанных таблиц в ваш dbcontext может быть не самым эффективным решением, и ef будет перетаскивать все таблицы, которые он может видеть либо как dbset, свойство навигации, либо как fluent configuration.

Однако, если вам нужно перейти от ролей к пользователям в вашем dbcontext, а объект user имеет свойства навигации, которые указывают на 100 таблиц, тогда ваше решение будет заключаться в этом конкретном dbcontext, чтобы сообщить ef игнорировать таблицы, которые вас не интересуют, что-то вроде modelbuilder.ignore(‘orders’), предполагая, что от пользователейвы можете каким-то образом перейти к заказам. таким образом, вы можете обрезать график, чтобы учитывать только те объекты, которые вам нужны.

Затем вам понадобится другой dbcontext для других сфер интересов: концепция называется ограниченным контекстом. (Ссылка Джули Лерман, Эрик Эванс DDD) Затем вам нужно выполнить больше работы в вашем приложении для поддержки нескольких контекстов БД в одном приложении, но это можно сделать — (см. Julie Lerman на enterprise ef) Однако, если вам нужен только один dbcontext в вашем приложении, где область действия вашей модели ограничена подмножеством таблиц, тогда это будетработа.

Я думаю, вы можете использовать ef power tools для просмотра диаграммы таблиц только для чтения в вашей модели dbcontext. Затем вы можете подтвердить, насколько хорошо проходит ваша обрезка.