Как подсчитать связанные объекты, не извлекая их в Entity Framework

Легкий; просто проецируйте на тип POCO (или анонимный):

var q = from d in Model.Discussions
        select new DiscussionPresentation
        {
            Subject = d.Subject,
            MessageCount = d.Messages.Count(),
        };

Когда вы посмотрите на сгенерированный SQL, вы увидите, что Count() выполняется сервером БД.

Обратите внимание, что это работает как в EF 1, так и в EF 4.

Если вы используете Entity Framework 4.1 или более позднюю версию, вы можете использовать:

var discussion = _repository.GetDiscussionCategory(id);

// Count how many messages the discussion has 
var messageCount = context.Entry(discussion)
                      .Collection(d => d.Messages)
                      .Query()
                      .Count();

Источник: http://msdn.microsoft.com/en-US/data/jj574232.

Я знаю, что это старый вопрос, но, похоже, это постоянная проблема, и ни один из приведенных выше ответов не дает хорошего способа работы с агрегатами SQL в представлениях списка.

Я предполагаю прямые модели POCO и Code First, как в шаблонах и примерах. Хотя решение SQL View удобно с точки зрения администратора баз данных, оно вновь ставит задачу параллельной поддержки как кода, так и структур базы данных. Для простых агрегированных SQL-запросов вы не увидите большого прироста скорости от представления. Чего вам действительно нужно избегать, так это множественных (n+1) запросов к базе данных, как в приведенных выше примерах. Если у вас есть 5000 родительских объектов и вы считаете дочерние объекты (например, сообщения на обсуждение), это 5001 SQL-запрос.

Вы можете вернуть все эти счетчики в одном SQL-запросе. Вот как.

1. Добавьте свойство-заполнитель в модель класса, используя аннотацию данных [NotMapped] из пространства имен System.ComponentModel.DataAnnotations.Schema. Это дает вам место для хранения рассчитанных данных без фактического добавления столбца в вашу базу данных или проецирования на ненужные модели представления.

   ...
   using System.ComponentModel.DataAnnotations;
   using System.ComponentModel.DataAnnotations.Schema;
   
   namespace MyProject.Models
   {
       public class Discussion
       {
           [Key]
           public int ID { get; set; }
   
           ...
   
           [NotMapped]
           public int MessageCount { get; set; }
   
           public virtual ICollection<Message> Messages { get; set; }
       }
   }
   

2. В вашем контроллере получите список родительских объектов.

   var discussions = db.Discussions.ToList();
   

3. Запишите количество в словарь. При этом создается один запрос SQL GROUP BY со всеми идентификаторами родительских объектов и количеством дочерних объектов. (Предположим, что DiscussionID — это FK в Messages.)

   var _counts = db.Messages.GroupBy(m => m.DiscussionID).ToDictionary(d => d.Key, d => d.Count());
   

4. Прокрутите родительские объекты, найдите количество в словаре и сохраните в свойстве-заполнителе.

   foreach (var d in discussions)
       {
           d.MessageCount = (_counts.ContainsKey(d.ID)) ? _counts[d.ID] : 0;
       }
   

5. Верните свой список обсуждений.

   return View(discussions);
   

6. Ссылка на свойство MessageCount в представлении.

   @foreach (var item in Model) {
       ...
       @item.MessageCount
       ...
   }
   

Да, вы можете просто вставить этот словарь в ViewBag и выполнить поиск непосредственно в представлении, но это запутает ваше представление кодом, который не должен там быть.

В конце концов, я бы хотел, чтобы у EF был способ «ленивого подсчета». Проблема как с ленивой, так и с явной загрузкой заключается в том, что вы загружаете объекты. И если вам нужно загрузить, чтобы считать, это потенциальная проблема с производительностью. Ленивый подсчет не решит проблему n+1 в списковых представлениях, но было бы неплохо иметь возможность просто вызывать @item.Messages.Count из представления, не беспокоясь о потенциальной загрузке тонн нежелательных данных объекта.

Надеюсь это поможет.

У меня нет прямого ответа, но я могу только указать вам на следующее сравнение между NHibernate и EF 4.0, которое, кажется, предполагает, что даже в EF 4.0 нет готовой поддержки для получения количества связанной коллекции сущностей без извлечения коллекция.

http://ayende.com/Blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx

Я проголосовал за ваш вопрос и отметил его звездочкой. Надеюсь, кто-нибудь подскажет работоспособное решение.

Я столкнулся с той же проблемой при работе с несколькими преобразователями, включая EF и DevExpress XPO (которые даже не позволяют одному объекту сопоставляться с несколькими таблицами). То, что я нашел лучшим решением, - это в основном использовать шаблоны EDMX и T4 для создания обновляемых представлений в SQL Server (с вместо триггеров), и таким образом у вас есть низкоуровневый контроль над sql, поэтому вы можете выполнять подзапросы в select предложение, использовать все виды сложных соединений для ввода данных и так далее.

Если это не единичный случай, и вам нужно подсчитать несколько различных связанных сущностей, представление базы данных может быть более простым (и, возможно, более подходящим) выбором:

1. Создайте представление базы данных.

   Предполагая, что вам нужны все исходные свойства объекта плюс связанное количество сообщений:

   CREATE VIEW DiscussionCategoryWithStats AS
   SELECT dc.*,
         (SELECT count(1) FROM Messages m WHERE m.DiscussionCategoryId = dc.Id)
             AS MessageCount
   FROM DiscussionCategory dc
   

   (Если вы используете Entity Framework Code First Migrations, см. этот ответ SO о том, как создать представление.)

2. В EF просто используйте представление вместо исходного объекта:

   // You'll need to implement this!
   DiscussionCategoryWithStats dcs = _repository.GetDiscussionCategoryWithStats(id);
   
   int i = dcs.MessageCount;
   ...