ASP.NET Entity Framework 6 HashSet lub lista dla kolekcji?

Question

Moje modele EF wyglądać następująco:

public class ContentStatus 
{ 
    public ContentStatus() 
    { 
     this.Contents = new List<Content>(); 
    } 

    public int ContentStatusId { get; set; } 
    public string Name { get; set; } 
    public virtual ICollection<Content> Contents { get; set; } 
} 

Jednak widziałem też implementatins wygląda tak:

public class ContentStatus 
{ 
    public ContentStatus() 
    { 
     this.Contents = new HashSet<Content>(); 
    } 

    public int ContentStatusId { get; set; } 
    public string Name { get; set; } 
    public virtual ICollection<Content> Contents { get; set; } 
} 

Oto DDL dla tego obiektu:

CREATE TABLE [dbo].[ContentStatus] (
    [ContentStatusId] INT   NOT NULL, 
    [Name]   NVARCHAR (50) NOT NULL, 
    CONSTRAINT [PK_ContentStatus] PRIMARY KEY CLUSTERED ([ContentStatusId] ASC) 
); 

Czy ktoś powiedz mi, z którego powinienem skorzystać, a nawet czy istnieje różnica i kiedy będę używał Listy oraz kiedy HashSet, jeśli to dotyczy.

Dzięki

Answer 1

Więc HashSet<T> jest definition

I List<T> nie ma tych możliwości.

Sądzę, że zależy to od pożądanych cech i wydajności (które na małych zestawach są pomijalne). Można obliczyć oba.

Wyniki (choć prawdopodobnie niewielkie różnice) będą widoczne w dwóch częściach, odczyt i zapis. Sean skomentował, że prawdopodobne będzie nałożenie kar za zapisy z powodu obliczeń kodu skrótu i ​​porównań unikalności. Ale czyta się bardzo szybko (o(1)).

Tak naprawdę, to wszystko zależy od pożądanych cech.

W moich projektach użyłbym List<T>, ale to jest mój rodzaj konwencji. Możesz określić własną konwencję, pod warunkiem, że się jej trzymasz.

Answer 2

To zależy od przypadku użycia, ale w większości przypadków można dodać element do kolekcji tylko raz, ponieważ na przykład każdy status jest stosowany tylko raz do treści. Wątpię, aby jedna treść pojawiała się dwukrotnie w statusie. Dlatego HashSet jest poprawną strukturą danych, ponieważ zapobiega duplikatom. W przypadku, gdy jeden element może być duplikowany Lista byłaby poprawna, ale nie spotkałem się z tym w praktyce i nawet nie wiem, jak EF by sobie z tym poradził.

Na marginesie doradzam, aby nie umieszczać kolekcji przedmiotów w swoich jednostkach, chyba że jest to potrzebne. Na przykład, jeśli tworzysz aplikację internetową do wyświetlania produktów, prawdopodobnie masz widok, w którym wyświetlasz pojedynczy produkt wraz z jego tagami. Dlatego produkt powinien mieć kolekcję Znaczników, aby ta sprawa była łatwa. Jednak prawdopodobnie nie masz strony wyświetlającej tag z kolekcją produktów, dlatego tag nie powinien mieć właściwości Produkty. Po prostu nie dba o produkty pokrewne. Wygląda na to, że ta encja Status nie dba o swój zbiór Treści.