Foreign Key и Guid.NewGuid(): неприятная мелочевка // .NET // 22.08.2013

Entity Framework — штука, серьезно облегчающая жизнь. Мне нравится вариант Code First, мне удобно практически не залезать в БД, кроме как для отладки. Что и сыграло злую шутку.

Создаю модель по типу:

public class Cart
{
[Key]
public int AnswerID { get; set; }
public virtual Answer Answer { get; set; }
(+ всякое разное, не имеющее отношения к делу
}


Казалось бы, и что тут такого? Сочетание AnswerID + виртуальной переменной Answer означает, что AnswerID — это foreign key для Answer; аннотация [Key] означает, что AnswerID надо использовать в качестве основного ключа. Ничего подобного! Вижу — не работает приложение. Проверяю переменные, нахожу одну проблему, связанную с генерацией guid:

guid something = Guid.NewGuid();

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

guid something = new Guid();

Выход из ситуации был прост, хотя и неочевиден:

string something = Convert.ToString(System.Guid.NewGuid());

В string, конечно, необязательно сразу превращать, просто было удобнее. Причем все namespace’ы на месте, причина осталась неясной. Главное — работает Потом натолкнулся на StackOverflow на похожее решение; видимо, не у одного меня проблема. Мелочь, а неприятно: глюк, которого не должно быть.
Но и после разборки с guid’ом приложение все равно выдавало null в месте, где вроде все должно быть в порядке. Оказалось, что в базе данных (куда я обычно и не залезаю) добавилось новое поле Answer_ID и именно оно и считалось Foreign Key. Использовать напрямую его все равно было нельзя (тогда появлялось еще одно новое поле, которое и использовалось как Foreign key), поэтому оставалось только вручную указать на Foreign key:

public class Cart
{
[Key]
public int AnswerID { get; set; }
[ForeignKey("AnswerID")]
public virtual Answer Answer { get; set; }
}


Почему нельзя в этом случае распространить соглашение по умолчанию — понятия не имею. Получается, что обычно работает одним образом, а в конкретном случае — другим. Не-у-доб-но Тоже мелочь, а неприятно: тут даже не баг, а самая настоящая фича Если бы вообще одно поле не могло быть сразу и Key, и Foreign Key — еще понятно. Так ведь может! Но не хочет.