Как создать вычислимое поле в модели Code First Entity Framework 6?

Question

[eugene73]

Добрый день.

Создаю модель данных Code First в Entity Framework 6. Появилась необходимость создать у сущности вычислимое свойство. Например, количество по документу есть сумма количеств по всем его строкам, потому хранить такое поле в таблице неправильно. На SQL я бы написал:

select *
, coalesce((select sum(r.Quantity) from DocumentRows r where r.document_id=d.id), 0) as Quantity
from Documents d
where

Как мне убедить Entity Framework при выборке из Documents создавать именно такой запрос, чтобы свойство Quantity у сущности Document было, а поля в таблице – не было?

Сущности описаны как-то так:

public partial class Document
{
public Guid id {get; private set; }

public virtual ICollection Rows {get; private set;}

...
}

public partial class DocumentRow
{
public Guid id {get; private set;}

public virtual Document Document {get; set;}

public decimal Quantity {get; set;}
...
}

Answer 1

[Евгений]

Создать partial класс для сущности Document под именем Document.MyExtensionBlaBla.cs; добавить в него новое свойство TotalQuantity и определить логику его вычисления:

public partial class Document
{
     public decimal TotalQuantity => Rows.Sum(x => x.Quantity)
}

Впоследствии, к этому свойству можно обращаться из инстанса Document. Например, так:

var totalSumByDocument = new dbCtx().Documents.Single(x => x.Id == id)).TotalQuantity;

Где id - входной параметр искомого документа, представляющий собой его уникальный идентификатор.

Comments

[eugene73]

Спасибо, это почти то, что надо. То есть, да, данные выбираются, но для того, чтобы рассчитать TotalQuantity по одному документу, выполняется 2 запроса: 1) собственно выборка реквизитов документа и 2) выборка строк. Да плюс еще постобработка на клиенте для суммирования по коллекции строк. Таким образом, если я захочу показать пользователю в гридушке n документов с количествами, система выполнит n+1 запрос. И результаты всех этих запросов в итоге будут занимать память клиента, пока вся коллекция документов не будет удалена, а польза от них только одна - посчитать суммарное количество. Как-то это неправильно, учитывая, что то же самое может посчитать один единственный запрос SQL.

[Евгений]

eugene73: я исходил из условий вашего вопроса: поле в SQL создавать нельзя(об этом ниже). К тому же, вы хотите сделать это с помощью EF.
Теперь о поле. Ход мыслей у Вас конечно правильный(зачем нам новое поле - это ведь сумма строк). Но нужно понимать масштабы. Представим, что у вас какая-то финансовая система с документами. Когда Вам нужно сделать сводный отчет за год - вы будете пересчитывать каждый раз сумму. Для системы с 1 пользователем и 1000 документов - ОК. Для 1000 пользователей с 100 000 документов(количество строк документов еще больше) - уже нет. Здесь, выходит, гораздо оптимальнее хранить промежуточное состояние суммы в отдельном поле(вычислять его при записи/изменении документа). А если документ рождает проводки на постоянной основе(и вместе с ним тысячи других), а общая сумма падает в какие-то таблицы накоплений? А если она еще участвует в N процессах? Решать только вам. На заметку: никто в тяжелом Enterprise не приводит таблицы к 5-6 НФ. В одном случае подсчет поля"на лету" - это "cheap operation", в другом - уже нет.

[eugene73]

Евгений: Да, насчет экстремальной нормализации я понимаю. Есть доводы за и против нее, но большая нагрузка на сервер при формировании отчетов – не мой случай. Кроме того, в Enterprise-системе никому никогда не придет в голову (на самом деле, случается) хранить или рассчитывать суммарное количество по документу уже хотя бы потому, что количества в разных строках одного документа могут быть в разных единицах измерения.
На самом деле, меня интересует более общий вопрос. Можно ли в принципе в сущности EF описать свойство, значение которого рассчитывалось бы на SQL-сервере? Например, дата предыдущего документа того же типа на SQL рассчитывается элементарно:

lag(DocumentDate) over (partition by DocumentType_id order by DocumentDate)

Хранить это значение было бы ну совсем уж странно.

Answer 2

[MrDywar Pichugin]

Был подобный вопрос и у меня, нашел это Computed Columns, работает только с той же таблицей где находится сущность.