После почти целого дня работы над этим я понял это! На самом деле, я нашел 2 разных способа решения этой проблемы, предполагая, что у меня та же проблема, что и у Крейга.
Во-первых, ответ driAn на самом деле не помогает (еще раз, если у Крэйга та же проблема, что и у меня), поскольку проблема в том, что в таблице А. нет отдельного внешнего ключа. Первичный ключ таблицы А точно такой же первичный ключ для таблицы B! В частности, в моем случае я использую представление и таблицу, а не две таблицы:
table A
-------
A_ID int
col1 int
col2 int
view A_extra
-------
A_ID int
col3 int
Итак, вот решения, которые я нашел:
1. Сопоставьте две разные сущности, но используйте взлом. Таким образом, вся проблема с ответом driAn заключается в том, что у нас нет отдельного столбца внешнего ключа для сопоставления, который мы затем можем удалить из свойств (мы не можем удалите его из свойств, потому что это первичный ключ представления A_extra!). Так что взломать безумно просто, как только вы это поймете: отредактируйте A_extra и просто создайте копию A_ID и сделайте его внешним ключом замены:
table A
-------
A_ID int
col1 int
col2 int
view A_extra
-------
A_ID int
A_FK_ID int
col3 int
A_FK_ID просто определяется как 'A_ID as A_FK_ID' в SQL представления, и он всегда будет иметь точно такое же значение, как A_ID.
Теперь, для структуры сущностей, это очень знакомый сценарий. Просто создайте связь 1-к-1, сопоставьте ассоциацию с A_extra и сопоставьте свойство A_ID в таблице A с A_FK_ID и свойство A_ID в A_extra с A_ID. Теперь вы больше не заставляете одну и ту же колонку выполнять двойную функцию согласно EF! Однако забавно то, что A_FK_ID всегда будет идентичен A_ID в A_extra.
Теперь у вас есть свойство навигации к A_extra, и col3 доступен, как вы и ожидали. Более того, вы по-прежнему можете изначально изменять table_A, так как EF видит, что это таблица (если вы сделали одно представление из этой комбинации и импортировали его в EF, вы не можете обновить его изначально).
2. Сопоставьте таблицу и представление с одной сущностью. Для этого решения вам не нужен хак, и это предпочтительно, потому что вам не нужно переходить через свойство навигации, чтобы перейти к col3.
Чтобы получить эту конфигурацию, добавьте A и A_extra в EF. Скопируйте и вставьте col3 из A_extra в A, так что теперь у вас есть несопоставленное свойство "col3", расположенное в A, и ничего в A_extra. Теперь перейдите к отображению для A и добавьте A_extra как представление для отображения (так, чтобы сущность «A» теперь отображалась как в таблицу «A», так и в представление «A_extra»). Сопоставьте свойство col3 (в объекте A) со столбцом col3 (в представлении A_extra). Теперь вот как вы показываете EF, как объединить эти два элемента для создания единого объекта: сопоставить столбец A_ID в A_extra с идентификатором свойства в объекте A. Если вы заметили, у вас теперь есть два столбца, сопоставленных с одним имущество. Это нормально, поскольку они представляют одно и то же, и именно так EF знает, как присоединиться к этому столбцу.
Теперь, чтобы закончить очистку, вам нужно удалить плавающую сущность "A_extra" в конструкторе. (Возможно, вы захотите убедиться, что он больше не отображается для просмотра A_extra, просто чтобы быть уверенным, что он также не убирает отображение магазина для A_extra - я надеюсь, что этого не произойдет, поскольку объект A теперь сопоставлен с ним). Теперь вы сможете создавать и получать доступ к col1, col2 и col3 из сущности A!
Круто то, что вы можете корректно обновить данные до col1 и col2, так как они сопоставлены с таблицей (A), но EF помешает вам, как следует, обновить col3, поскольку они сопоставлены с представлением (A_extra) , Это удобнее, чем сделать A комбинированным представлением в БД и импортировать его, потому что EF помешает вам обновить любых столбцов, поскольку они все из представления, насколько это касается.
Уфф, я так рад, что наконец-то это сработало. Надеюсь, мои решения помогли вам, ребята!
-Роберт