#.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 Ядром являются Отношения . Он содержит определение терминов и множество примеров, в том числе одно свойство навигации , хотя оно предназначено для свойства навигации по коллекции с одной стороны, но то же самое относится и к ссылочной навигации со многих сторон.