Объединения EF и представления MVC Razor

У меня есть несколько таблиц, отношения которых основаны на уникальных ключевых ограничениях.

Быстрый пример:

VersionId, VersionName
SurveyId, SurveyName, VersionId
QuestionId, QuestionName, SurveyId, VersionId

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

Нужен ли мне анонимный тип? db.Questions.Include("Опросы"), похоже, ничего не делает. Я мог бы использовать linq и создать ViewModel из соединенных таблиц (я подозреваю, что это правильный путь), но в EF и MVC так много вещей, что я решил проверить, прежде чем что-либо делать.


entity-framework asp.net-mvc razor asp.net-mvc-3
person Bennett Dill    schedule 03.08.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Почему у вас есть ссылка на версию (т. е. VersionID) как в таблице опроса, так и в таблице вопросов? Не могли бы вы дойти до версии из вопроса через опрос?

Кроме того, если у вас есть связь между Вопросом и Опросом "многие к одному" или "один к одному" (каждый вопрос имеет только один опрос), тогда она должна быть db.Questions.Include("Survey") – не во множественном числе.

person dnatoli    schedule 04.08.2011
comment
Простой ответ на вопрос, почему версия находится под вопросом, заключается в том, что есть другие таблицы, которые зависят от версии, связанной с вопросом. Чтобы убедиться, что, скажем, ответ является подходящей версией для вопроса, мне нужна версия самой таблицы вопросов. - person Bennett Dill; 04.08.2011
comment
При использовании Include для чего-либо я не получаю никаких дополнительных свойств для результирующих сущностей... Я подозреваю, что это связано с тем, что структура сущностей не знает об ограничениях уникальных ключей, поэтому она пропускает/игнорирует внешние ключи на их основе. - person Bennett Dill; 04.08.2011
comment
У меня есть составной ключ для обеспечения ссылочных ограничений в самой базе данных. Ваш вопрос побудил меня создать ассоциацию EF только с соответствующими данными. И это сработало как чемпион! Затем мне пришлось обновить мою схему, и я подумал... Избыточные отношения не повредят в базе данных, поэтому я добавил кучу отношений, соединяющихся только по одному ключу вместо составного ключа и BAM, все связано с добром EF. Спасибо за вдохновение :-) - person Bennett Dill; 05.08.2011

arrow_upward
1
arrow_downward

Во-первых, никаких объединений (или практически любой другой логики) в представлениях бритв. Контроллер — это место для создания ViewModel, а представления — это средства для представления этой ViewModel. Как вы упомянули, создание ViewModel для него — единственный (правильный) путь. И вы можете заполнить эту модель представления любым способом - linq - это абсолютно нормальный способ создания объединенных данных. И если вы хотите пойти дальше, вы должны поместить эту логику соединения в какой-то репозиторий, например QuestionRepository, а не в контроллер.

person archil    schedule 04.08.2011
comment
Ааа, репозиторий вопросов, а не контроллер, мне это нравится :-) Я изо всех сил старался сохранить всю логику, относящуюся к объекту, в связанном с ним контроллере... - person Bennett Dill; 04.08.2011