Entity Framework: когда использовать Set <>

Я пытаюсь понять основы Entity Framework, и у меня есть вопрос о методе Set < > в DbContext. Я использую первую модель базы данных для следующего вопроса.

Скажем, у меня есть база данных ActivityLog, которая, среди прочего, я могу использовать для вывода сообщения (например, сообщение NLog). Я мог бы написать код, чтобы вытащить все сообщения вроде этого:

using (var entities = new ActivityLogEntities())
    foreach (var log in entities.AcitivityLogs)
        Console.WriteLine(log.Message);

Однако я мог бы также добиться того же самого:

using (var entities = new ActivityLogEntities())
    foreach (var message in entities.Set<ActivityLog>().Select(entity => entity.Message))
        Console.WriteLine(message);

Мой вопрос в чем разница между этими двумя утверждениями? Когда более целесообразно использовать один над другим? Или это только вопрос личных предпочтений?

Ответ 1

Там нет существенной разницы. В первом случае у вас есть что-то вроде:

class MyContext : DbContext
{
    public DbSet<AcitivityLog> AcitivityLogs { get; set; }
}

Когда контекст создает, он ищет общедоступные DbSet<T> свойства read/write и делает это (псевдокод):

dbSetProperty = Set<EntityType>();

Но есть случаи, когда вы:

1) не хотят создавать общедоступные свойства для всех типов сущностей.
2) не знают всех типов сущностей во время разработки контекста.

В этих случаях Set<T> - единственный способ получить правильный набор объектов.

Ответ 2

Единственная причина, по которой я когда-либо использовал Set<T>, - это когда вы действуете на тип, который вы не знаете, например, общая вставка.

Вот пример из моего общего репозитория:

  public void AddOnSave(T entity)
  {
     ctx.Set<T>.Add(entity);
  }

Использование этого для обычного материала просто делает код менее читаемым IMHO

Ответ 3

Если вы посмотрите на сгенерированный класс DbContext, вы увидите, что AcitivityLogs - это просто DbSet<ActivityLog>.

Таким образом, они - одно и то же. Это просто типизированное определение вашего DbSet.