Основные свойства навигации и соединения Entity Framework, Правильный шаблон

#.net-core #entity-framework-core

Вопрос:

Я изо всех сил пытаюсь понять, как лучше всего реализовать некоторые отношения с базой данных в EF Core.

В частности, это включает в себя свойства навигации, в которых вы создаете коллекцию в родительском объекте и объект в дочернем.

Просматривая документы MS здесь

Связи, свойства навигации и внешние ключи

существует типичный пример использования родительско-дочерних отношений

 public class Course
{
  public int CourseID { get; set; }
  public string Title { get; set; }
  public int Credits { get; set; }
  public int DepartmentID { get; set; }
  public virtual Department Department { get; set; }
}

public class Department
{
   public Department()
   {
     this.Courses = new HashSet<Course>();
   }  
   public int DepartmentID { get; set; }
   public string Name { get; set; }
   public decimal Budget { get; set; }
   public DateTime StartDate { get; set; }
   public virtual ICollection<Course> Courses { get; set; }
}
 

Теперь это подходит для приведенного выше варианта использования.

Тем не менее, я работаю над системой спецификаций для технологических рецептов. Здесь задействовано множество машин, материалов, площадей, зданий и других вещей.

Одна из таблиц в базе данных — «Единица измерения», как в единицах измерения, то есть кг, м, см и т.д.

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

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

 pubic class Unit
{
  public Guid Id { get; set; }
  public string Name { get; set; }
  public virtual ICollection<Recipes> Recipes{ get; set; }
  public virtual ICollection<Coll2> Coll2{ get; set; }
  public virtual ICollection<Coll3> Coll2{ get; set; }
  public virtual ICollection<Coll4> Coll2{ get; set; }
  public virtual ICollection<Coll5> Coll2{ get; set; }
  public virtual ICollection<Coll..n> Coll..n{ get; set; }
}
 

Это относится не только к единице измерения, но и к целому ряду других общих элементов поиска, таких как склад. Существует множество организаций, которые используют ссылку на склад.

Каков правильный подход при использовании такого рода поиска?

Мне жаль, если что-то не ясно, надеюсь, так оно и есть.

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

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

2. Хорошо, спасибо вам за такой быстрый ответ. Проблема, которая затем сбивает меня с толку, заключается в том, как правильно загрузить данные поиска. Еще раз спасибо вам.

3. Я не понимаю. Возможно, вам следует отредактировать свой вопрос и объяснить этот аспект.

4. Ну, вы не поймете, я этого не объяснял :), но спасибо. Я работал над перемещением большого приложения, которое является бэкэндом Django (мир, с которым я гораздо лучше знаком), на использование .net core. Мне очень нравится концепция подхода code first EF, система идентификации, а также то, как вы можете легко разделять проблемы — особенно по сравнению с тем, что Python может предложить с различными фреймворками. Проблема в том, что, по-видимому, существует множество способов достичь одного и того же, и трудно понять, что лучше. Документация очень трудна для понимания и, наоборот, лаконична, имхо.

5. Вы смотрите не ту документацию (для EF6). Соответствующим для EF Ядром являются Отношения . Он содержит определение терминов и множество примеров, в том числе одно свойство навигации , хотя оно предназначено для свойства навигации по коллекции с одной стороны, но то же самое относится и к ссылочной навигации со многих сторон.