У меня есть две таблицы с именем Profile и ProfileHistory. Каждая запись в ProfileHistory должна принадлежать профилю в таблице Profile, поэтому между двумя таблицами существует отношение внешнего ключа. Кроме того, в таблице ProfileHistory есть столбец с именем ManagerId, который также относится к таблице Profile с отношением внешнего ключа.
Id int primary key........
Идент. Первичный ключ
Внутренний ключ ProfileId для таблицы профилей
ManagerId int foreign key для таблицы профилей
....
Мой вопрос: так как в настоящее время я знаю только это, я создаю свою модель сущности из базы данных. Модель и, следовательно, классы объектов создаются с навигационными свойствами в объекте ProfileHistory, например:
public virtual Profile Profile { get; set; }
public virtual Profile Profile1 { get; set; }
Это так запутанно. Потому что неясно, какое навигационное свойство для какого отношения. Даже хуже, если у меня больше отношений между двумя таблицами. имена свойств навигации становятся Profile, Profile1, Profile2 и т.д. Я ожидал названия свойств навигации, связанных с его отношениями с внешним ключом.
Как я могу сделать свои имена свойств навигации чем-то, что связано с его отношением внешнего ключа, в моем случае "от профиля1 до профиля"?
Заранее благодарим за помощь.
Muharrem
Вы всегда можете переименовать свойства в диаграмме модели. Имя можно найти в окне "Свойства", когда вы нажмете на свойство навигации.
Я не тестировал его, но вы можете сопоставить свойство с столбцом, используя атрибут:
[Column("BlogDescription", TypeName="ntext")]
public virtual Profile Profile { get; set; }
[Column("Profile1", TypeName="int")]
public virtual Profile ProfileManager { get; set; }
Измените тип и имя столбца, как в базе данных.
Как я обычно решаю это, нужно добавлять свойства через частичные классы, которые лучше отражают то, что мне нужно. Таким образом, если мне нужно удалить объект из диаграммы и повторно добавить его, я не потеряю переименованные столбцы из модели.
Недостатком этого является то, что вам нужно помнить, что вы не можете использовать их в запросах, потому что EF не будет знать, как перевести его в SQL-запрос. Но если у вас уже есть свой профиль, гораздо проще получить доступ к myProfile.Manager, чем myProfile.Profile1.
Так, например, если EF создала это для вас:
public partial class ProfileHistory
{
public virtual Profile Profile { get; set; }
public virtual Profile Profile1 { get; set; }
}
Я бы в конечном итоге создал частичный класс, подобный этому, чтобы перегруппировать столбцы:
public partial class ProfileHistory
{
public Profile Manager
{
get
{
return this.Profile1;
}
set
{
this.Profile1 = value;
}
}
}
Некоторое время назад я столкнулся с той же проблемой. Ну, это даже больше, чем просто путающие имена. Если у вас есть свойства навигации для другой таблицы, например Profile
, Profile1
, Profile2
, то после удаления или редактирования соответствующих внешних ключей вы можете столкнуться со смешанными. И если вы использовали EntitySQL
для запроса данных, у вас EntitySQL
ошибки из-за неправильных данных, полученных/неправильных условий объединения таблиц...
То, что я сделал, это изменить шаблон t4
и изменить способ создания свойств. Когда текст кода свойства записывается, у вас есть информация об ассоциации и внешнем ключе, связанном с ним. Имена внешних ключей уникальны в базе данных, и я назвал те, у кого следующий шаблон
FK_[Table]_[Meaning]
...
FK_ProfileHistory_InitialProfile
FK_ProfileHistory_UpdatedProfile
Затем, имея эту информацию, я назвал свойства с [Meaning]
частью имени внешнего ключа.