0

我對投票系統實現感到困惑。我想知道投票並投票減少郵報的數量,也可以保存投票的選民。我使用下面的模型。關於實現投票系統的模型關係

public class Post : Entity 
{ 
    public string Title { get; set; } 
    public virtual User Owner { get; set; } 
    public virtual List<User> UpVoters { get; set; } 
    public virtual List<User> DownVoters { get; set; } 
} 

我覺得有點問題在本設計中,因爲如果我有機會代表投票並否決後的數,所以我想我必須處理2 query.Using導航性能計數,如果會導致性能問題我只需要計數。我對嗎?

下面的第二個問題也讓我感到困惑,因爲VoteUpCount和VoteDownCount應該由開發人員隨時處理。當選民改變他的投票時總是重新更新值,這看起來有點代碼味道。

public class Post : Entity 
{ 
    public string Title { get; set; } 
    public virtual User Owner { get; set; } 
    public int VoteUpCount { get; set; } 
    public int VoteDownCount { get; set; } 
    public virtual List<User> UpVoters { get; set; } 
    public virtual List<User> DownVoters { get; set; } 
} 

您能否提供我哪些比較好?爲什麼更好?我有另一種選擇嗎?

Lastyly post hold 3用戶導航屬性,這讓我覺得有些東西可能是錯的。這種關係有什麼不妥?

回答

2

出於本能,我想創建一個投票實體,既然你想節省票信息:

public class Vote : Entity 
{ 
    public User User {get;set;} 
    public int VoteDirection {get;set;} // 1 or -1 
    // any other info... 
} 

然後添加投票場中郵類:

public class Post : Entity 
{ 
    public string Title { get; set; } 
    public virtual User Owner { get; set; } 
    public virtual List<Vote> Votes { get; set; } 
} 

然後你算總和VoteDirection對於每個投票...

1

我不認爲這裏有什麼問題。

你的第一個模型對我來說很不錯。除非你能證明獲得相關實體數量的性能受到影響,否則我不會去第二個。 不成熟的優化是所有邪惡的根源 ;-)。

如果因性能原因需要存儲計數,那麼第二個模型也可以。只要確保添加投票更新計數字段。

1

你的第一個模型是正確的,你不應該爲EF的缺點妥協模型,第二個版本也不是很好維護 - 這涉及到太多的思考和手動工作。

實際上沒有爲EF物化所有相關實體的時候,你要檢索的數一種變通方法,語法不是很直觀,但會導致正確的SQL查詢:

var myPost = context.Posts.First(); 
int upvotersCount = context.Entry(myPost) 
          .Collection(p => p.UpVoters) 
          .Query() 
          .Count(); 

這種做法是詳細here

另外作爲一般的經驗法則,您應該使用ICollection<User>代替模型中的具體List<User>

1

Using navigation properties counts would cause performance problems if i just need counts. Am i right? - 你有什麼樣的性能問題?

通常情況下,添加計數字段會在數據庫中引入冗餘,但這是一個明顯的性能優化步驟。如果我是你,我寧願問自己是否需要改善這種情況下的表現。數據庫中會有多少帖子和投票?有多少用戶將同時訪問這些信息?等等。如果您的應用程序需要真正的可擴展性,您可以添加額外的計數並確保它們已正確更新。否則,你可以牢記這種可能性,但不要急於執行它。