2013-10-02 3 views
0

Я новичок в Entity Framework, и я борюсь с базой данных, созданной из моих классов POCO. У меня есть общий класс, который выглядит следующим образом:EF один для многих со ссылкой таблицы

public class Comment 
{ 
    public int Id { get; set; } 
    public string Text { get; set; } 
    public DateTime CreatedDate { get; set; } 
} 

и комментарии могут быть добавлены ко многим объектам, позволяет сказать, что, например, Человек и автомобиль, так что я буду иметь эти классы

public class Person 
{ 
    public int Id { get; set; } 
    public List<Comment> Comments { get; set; } 
} 

и

public class Vehicle 
{ 
    public int Id { get; set; } 
    public List<Comment> Comments { get; set; } 
} 

Когда EF генерирует мою базу данных, он добавляет Person_Id и Vehicle_Id, что для меня неверно, потому что: a) Это предполагает, что комментарий относится к человеку AND av ehicle, где он должен быть действительно свободным объектом b) Комментарии могут быть добавлены к будущим объектам, для которых потребуется изменение таблицы.

Как я могу получить EF, чтобы скорее использовать ссылку для этого?

(Примечание: я не могу и не хочу добавлять свойства навигации в класс комментариев, так как это потребует изменения класса каждый раз, когда новый объект нуждается в комментариях, а мой класс комментариев находится в моей общей библиотеке, не связанной с людьми или транспортными средствами)

Я нашел эту статью, но я изо всех сил, чтобы получить мой ответ от него: http://weblogs.asp.net/manavi/archive/2011/05/17/associations-in-ef-4-1-code-first-part-6-many-valued-associations.aspx

ответ

0

EF генерирует Person_Id и Vehicle_Id столбцы на Comment таблицы, которые обнуляемым. Это означает, что Комментарии могут быть связаны с Лицом ИЛИ Транспортным средством, либо как с Лицом, так и с транспортным средством ИЛИ Ни с кем. Таким образом, это является действительно «свободно стоящим» объектом.

Модель, которую вы, вероятно, ищете, использует inheritance.

public class Comment 
{ 
    public int Id { get; set; } 
    public string Text { get; set; } 
    public DateTime CreatedDate { get; set; } 
} 

public class VehicleComment : Comment 
{ 
    public int VehicleID; 
} 

public class PersonComment : Comment 
{ 
    public int PersonID; 
} 


public class Person 
{ 
    public int Id { get; set; } 
    public List<PersonComment> Comments { get; set; } 
} 

public class Vehicle 
{ 
    public int Id { get; set; } 
    public List<VehicleComment> Comments { get; set; } 
} 

EF по умолчанию наследует наследование на иерархию. Это создаст таблицу, аналогичную той, которая у вас уже есть, но столбец «Дискриминатор». Затем вы можете напрямую работать с DbSet<VehicleComment>, а не запрашивать DbSet<Comment> ... Where(x => x.Vehicle_Id != null), чтобы получать комментарии о транспортных средствах.

Да, комментарии, добавленные к будущим объектам, потребуют изменения таблицы, но это не совсем сложно при использовании кода First. И писать код становится намного проще, потому что вы не собираетесь через какой-то объект связывания.

EDIT Изменения, которое происходит, когда вы добавляете новый объект с отношением к Комментариям является то, что другим столбец внешнего ключа добавляется в таблицу Комментариев к модели этих отношений. Добавление столбца с нулевым значением в существующую таблицу, вероятно, является простым изменением схемы, которое вы можете получить. Что касается управления изменениями, вы все равно добавляете таблицу для новой сущности - так что у вас есть файл миграции, содержащий несколько дополнительных строк кода.

Кроме того, наличие связующего стола означает отказ от ограничений внешнего ключа, каскадные удаления и т. Д., Не так ли?

public class FooComment : Comment 
{ 
    //FooID means one more column in the table 
    public int FooID; 
} 

public class Foo 
{ 
    public int Id { get; set; } 
    public List<FooComment> Comments { get; set; } 
} 
+0

Спасибо за предложения, мое беспокойство по поводу изменения таблицы в будущем не так много трудностей, связанных, но больше контроля изменений, связанный, это на самом деле над упрощением моего требования, в моем приложении это может иметь большие проблемы с реализацией , Плюс с точки зрения схемы, я думаю, что ее неправильная необходимость обновлять общий объект для каждого объекта, который может ссылаться на него, можно спорить в обоих направлениях, но мне это не нравится. Я буду тестировать ваше предложение, но если он создаст таблицу PersonComment и таблицу VehicleComment, она, вероятно, не сработает для меня. –

+0

@AdriaanDavel Table Per Hierarchy создает одну таблицу для всех комментариев - аналогичную той, которая у вас уже есть, но с «Дискриминатором» ". См. Мое редактирование, что фактически меняется при использовании TPH. – Colin

Смежные вопросы