Блог

У меня есть некоторое недопонимание того, как мои объекты должны быть представлены в реляционной структуре БД.

Например, если у меня есть простая структура таблиц, которая выглядит следующим образом:

И если я создам модель Entity Framework на основе этого, это будет выглядеть как:

Как вы можете видеть, это ассоциация «многие ко многим». (Любое блюдо содержит много ингредиентов, любой ингредиент можно использовать во многих блюдах)

Теперь, что, если мне понадобятся какие-то дополнительные параметры, например, количество ингредиента в блюде? (Конечно, обычно это было бы отдельное число для каждого ингредиента в любом другом блюде).

Если я добавлю несколько дополнительных столбцов непосредственно в Dish_FooIngridient таблицу, это нарушит удобство автоматической генерации модели, и тогда мне придется исправлять ассоциации вручную в EF model designer, а позже использовать некоторые громоздкие запросы для работы с объектами. Потому что она будет сгенерирована во что-то вроде этого:

Как вы можете видеть, теперь есть другие избыточные свойства, которые мне не нужны. Есть ли лучший способ управлять этим? Может быть, используя сложные свойства или унаследованный объект, или что-то еще?

Как предлагается в «Рецептах Entity Framework 4.0 от Apress», проектирование отношений «Многие ко многим» без полезной нагрузки не очень хорошая практика.

К сожалению, проект, который начинается с нескольких отношений «многие ко многим» без полезной нагрузки, часто заканчивается несколькими отношениями «многие ко многим», богатыми полезной нагрузкой. Рефакторинг модели, особенно в конце цикла разработки, для размещения полезных нагрузок в отношениях «многие ко многим» может быть утомительным. Вводятся не только дополнительные объекты, но также изменяются запросы и шаблоны навигации через отношения. Некоторые разработчики утверждают, что каждое отношение «многие ко многим» должно начинаться с некоторой полезной нагрузки, обычно синтетического ключа, поэтому неизбежное добавление дополнительной полезной нагрузки оказывает значительно меньшее влияние на проект. Итак, вот наилучшая практика. Если у вас отношение «многие ко многим» без полезной нагрузки и вы считаете, что существует некоторая вероятность того, что со временем оно может измениться и включить полезную нагрузку, начните с дополнительного столбца identity в таблице link. Когда вы импортируете таблицы в свою модель, вы получите два отношения «один ко многим», что означает, что написанный вами код и имеющаяся у вас модель будут готовы к любому количеству дополнительных столбцов полезной нагрузки, которые появятся по мере развития проекта. Стоимость дополнительного столбца целочисленных идентификаторов обычно является довольно небольшой платой за то, чтобы сделать модель более гибкой.

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

Дважды щелкните файл Model.edmx, затем в пустом месте рядом с вашими объектами щелкните правой кнопкой мыши и выберите «Обновить модель из базы данных …», затем нажмите Готово, и это обновит ваши таблицы.