Entity Framework 4 CTP 5 POCO — таблица «многие ко многим» или таблица поиска?

Я создаю приложение для личного блога только с Entity Framework 4 CTP 5 POCO, где публикация может иметь много тегов, а тег может быть во многих Сообщениях. Мой вопрос заключается в том, строить ли модель «многие ко многим» или иметь таблицу поиска.

Сначала я пытался использовать многие ко многим, но я не знаю, как сделать вставку, каждый раз, когда публикуется новый пост (со многими выбранными тегами), я не уверен, что делать, чтобы теги должен быть связан с сообщением (и не будет вставлять новый тег, если имя тега уже существует).

Затем я пытаюсь создать таблицу поиска следующим образом:

Опубликовать

public class Post
{
    public int Id { get; set; }

    [Required]
    [StringLength(512, ErrorMessage = "Title can't exceed 512 characters")]
    public string Title { get; set; }

    [Required]
    [AllowHtml]
    public string Content { get; set; }

    public string FriendlyUrl { get; set; }
    public DateTime PostedDate { get; set; }
    public bool IsActive { get; set; }

    public virtual ICollection<Comment> Comments { get; set; }
    public virtual ICollection<PostTagLookup> PostTagLookups { get; set; }
}

Тег

public class Tag
{
    public int Id { get; set; }

    [Required]
    [StringLength(25, ErrorMessage = "Tag name can't exceed 25 characters.")]
    public string Name { get; set; }
    public string FriendlyName { get; set; }
    public virtual ICollection<PostTagLookup> PostTagLookups { get; set; }
}

Поиск тегов записей

public class PostTagLookup
{
    public int PostId { get; set; }
    public int TagId { get; set; }
}

Проблема в том, что я не уверен, как EF будет обрабатывать таблицу поиска (как я получу теги сообщения или коллекцию сообщений при выборе тега). И с приведенным ниже кодом я получил сообщение об ошибке, говорящее, что у PostTagLookup нет ключа Id:

var getPosts = _post.GetLatestPosts(3).ToList();

var posts = from post in getPosts
        select new PostModel
        {
            Id = post.Id,
            Title = post.Title,
            Content = post.Content,
            FriendlyUrl = post.FriendlyUrl,
            PostedDate = post.PostedDate,
            IsActive = post.IsActive,
            NumberOfComments = post.Comments.Count(),
            PostTags = post.PostTagLookups.Where(p => p.PostId == post.Id).ToList()
        };

Любое предложение о том, как выполнить эту задачу? Большое тебе спасибо!


asp.net-mvc lookup many-to-many entity-relationship entity-framework-4
person Saxman    schedule 03.01.2011    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Я думаю, что ваша модель должна работать как есть с небольшой настройкой: добавьте столбец/поле идентификатора в объект PostTagLookup.

public class PostTagLookup
{
    [Key]
    [DatabaseGenerated(DatabaseGenerationOption.Identity)]
    public int PostTagLookupId { get; set; }

    //etc.
}

Однако я не уверен, почему вы не хотите, чтобы EF самостоятельно обрабатывал лежащие в основе многие ко многим. Когда у вас есть новый объект Post, например, все, что вам нужно сделать, это добавить любые связанные теги в созданную коллекцию тегов сообщения перед вызовом SaveChanges() в вашем контексте. Это не сработало для вас?

person AJ.    schedule 03.01.2011
comment
Я пробовал многие ко многим, но не работал (это мой первоначальный вопрос: stackoverflow.com/questions/4571188/), выдает ошибку о чем-то, связанном с тем, что экземпляр объекта не был создан после The_Smallest предположение. Затем есть еще одно предложение, в котором говорится, что я должен использовать таблицу поиска без столбца Id! - person Saxman; 04.01.2011

arrow_upward
0
arrow_downward

Я боролся с этим последние пару дней и решил использовать таблицу поиска, как и предполагалось, и в таблице поиска также есть ссылки на модель сообщений и тегов как таковые:

public class PostTagLookup
{
    public int Id { get; set; }
    public int PostId { get; set; }
    public int TagId { get; set; }

    public virtual Post Post { get; set; }
    public virtual Tag Tag { get; set; }
}

Возможно, это не лучший способ, но он работает :) Спасибо всем за внимание.

person Saxman    schedule 06.01.2011