Использование hashset в структуре сущности

Я хочу знать, в чем разница между созданием классов с использованием или без использования hashset в конструкторе.

Используя первый подход к коду (4.3), можно создать такие модели типа:

public class Blog
 {
     public int Id { get; set; }
     public string Title { get; set; }
     public string BloggerName { get; set;}
     public virtual ICollection<Post> Posts { get; set; }
  }

public class Post
 {
    public int Id { get; set; }
    public string Title { get; set; }
    public DateTime DateCreated { get; set; }
    public string Content { get; set; }
    public int BlogId { get; set; }
    public ICollection<Comment> Comments { get; set; }
 }

или может создавать такие модели:

public class Customer
{
    public Customer()
    {
        BrokerageAccounts = new HashSet<BrokerageAccount>();
    }
    public int Id { get; set; }
    public string FirstName { get; set; }
    public ICollection<BrokerageAccount> BrokerageAccounts { get; set; }
}

public class BrokerageAccount
{

    public int Id { get; set; }
    public string AccountNumber { get; set; }
    public int CustomerId { get; set; }

}

Что здесь делает hashset?

Должен ли я использовать hashset в первых двух моделях?

есть ли какая-либо статья, которая показывает приложение hashset?

Ответ 1

Я новичок в Entity Framework, но это мое понимание. Типы коллекций могут быть любого типа, который реализует ICollection<T>. На мой взгляд, HashSet обычно является семантически правильным типом коллекции. В большинстве коллекций должен быть только один экземпляр участника (без дубликатов), и HashSet лучше всего это выражает. Я писал свои уроки, как показано ниже, и это хорошо работает. Обратите внимание, что коллекция набирается как ISet<T>, а сеттер является закрытым.

public class Customer
{
    public Customer()
    {
        BrokerageAccounts = new HashSet<BrokerageAccount>();
    }
    public int Id { get; set; }
    public string FirstName { get; set; }
    public ISet<BrokerageAccount> BrokerageAccounts { get; private set; }
}

Ответ 2

Вообще говоря, лучше всего использовать коллекцию, которая наилучшим образом выражает ваши намерения. Если вы специально не намереваетесь использовать уникальные характеристики HashSet, я бы не использовал его.

Он неупорядочен и не поддерживает поиск по индексу. Кроме того, он не подходит для последовательных чтений в качестве других коллекций, а тот факт, что он позволяет вам добавлять один и тот же элемент несколько раз без создания дубликатов, полезен только в том случае, если у вас есть причина использовать его для этого. Если это не ваше намерение, оно может скрыть неправильный код и затруднить проблему.

HashSet в основном полезен в ситуациях, когда время вставки и удаления очень важно, например, при обработке данных. Это также чрезвычайно полезно для сравнения наборов данных (опять же при обработке) с использованием таких операций, как intersect, except и union. В любой другой ситуации недостатки обычно превосходят профессионалов.

Учтите, что при работе с сообщениями в блогах вставки и удаления встречаются довольно редко по сравнению с чтениями, и вы вообще хотите читать данные в определенном порядке. Это более или менее полная противоположность тому, на что хорошо работает HashSet. Очень сомневаюсь, что вы когда-нибудь захотите дважды добавить одну и ту же запись по какой-либо причине, и я не вижу причин, по которым вы бы использовали операции с множествами на должностях в таком классе.

Ответ 3

HashSet не определяет тип коллекции, который будет сгенерирован при фактическом извлечении данных. Это всегда будет иметь тип ICollection, как указано.

HashSet, созданный в конструкторе, поможет вам избежать NullReferenceExceptions, когда никакие записи не извлекаются или не существуют во многих сторонах отношения. Это никоим образом не требуется.

Например, на основе вашего вопроса, когда вы пытаетесь использовать отношения типа...

var myCollection = Blog.Posts();

Если нет сообщений, то myCollection будет null. Что все в порядке, пока вы не будете свободно говорить о вещах и делаете что-то вроде

var myCollectionCount = Blog.Posts.Count();

который будет ошибочен с помощью NullReferenceException.

Где

var myCollection = Customer.BrokerageAccounts();
var myCollectionCount = Customer.BrokerageAccounts.Count();

приведет к и очистке ICollection и нулевому счету. Нет исключений: -)