У меня проблема с производительностью в рамках сущностей.
Вот сценарий.
У меня есть сущность, которая называется "Сегмент". Каждый из них хранится в отдельной таблице в БД.
«Сегменты» имеют настраиваемое свойство «IsHPMSSegment», которое является вычисляемым полем. Он рассчитывается путем вызова хранимой процедуры в БД, которая берет «ID» «Сегмента» и сравнивает некоторые ее значения со значениями в другой таблице.
Один из запросов, который нам нужно выполнить, сформулирован следующим образом: Получите все сегменты, которые являются сегментами HPMS.
Так как значение «ISHPMSSegment» для «Segment» является настраиваемым свойством, я не могу получить его значение непосредственно из БД при первом выборе сегментов. Вместо этого, поскольку каждый «Сегмент» создается в наборе результатов, структура сущностей снова запрашивает базу данных, чтобы получить значение для «IsHPMSSegment». Таким образом, каждый раз, когда «Сегмент» заполняется, он должен снова запрашивать БД для каждого возвращаемого Сегмента.
Пример: если я получу все «Сегменты» с идентификатором, превышающим 5, и набор результатов будет 1000 сегментов, то к БД будет обращено всего 1001 раз. Один раз для первоначального запроса выбора, который получает 1000 записей, а затем еще 1000 раз, чтобы заполнить значение «IsHPMSSegment» каждого из «сегментов».
Единственный обходной путь, который я могу придумать, - создать представление в БД («vSegments»), которое содержит это дополнительное вычисляемое свойство, а затем связать мой объект EF с этим представлением, а не с таблицей «Сегмент». Таким образом, это свойство будет заполнено в первом запросе.
У меня есть два варианта для оставшейся функциональности (вставка, обновление, удаление):
1) подключить мои функции вставки, обновления и удаления объекта для хранимых процедур
2) сделать вид обновляемым
Все это, похоже, требует дополнительной работы только для решения этой проблемы с производительностью, и я задаюсь вопросом, какая польза от использования EF вообще?
Есть ли лучшее решение для идеи "представление + хранимые процедуры", о которой я говорил выше (все еще с использованием EF)?
Если нет, какую выгоду дает мне EF? Если бы я создавал свой собственный DAL с нуля, мне все равно пришлось бы создавать хранимые процедуры и / или представления. Сколько усилий я действительно экономлю, используя EF и программируя вокруг его ограничений?
Помимо всего этого, EF, по-видимому, не справляется с обновлением нескольких записей одновременно удовлетворительным образом. Он отправляет один вызов оператора update для каждой обновляемой записи, даже если вы обновляете их все одинаково. Это также может показаться недоброжелателем (если для этого не существует какого-то обходного пути, о котором я не знаю).