Получаем данные enum в проекции Automapper

[workless]

оффтоп
Automapper плох тем, что его автор очень часто делает ломающие изменения.
Как написали на иностранном форуме «Похоже его разработчик сидит на тяжелых наркотиках»

Как только что-то начнете использовать отличное от тривиального маппинга — то скорее всего будет тяжело обновиться на следующую версию.

[AgentFire]

А как дела обстоят с сортировкой и фильтрацией на конечном потребителе?
Что, если полученный IQueryable требуется передать дальше по логической цепочке, где будут применены Where/OrderBy и т.п.?

[alexeystarchikov]

Проблем с этим нет. В результате же получается SQL-запрос, к которому, соответственно, можно применить WHERE/ORDER BY

[AgentFire]

Но каким же образом они транслируются в SQL?

[alexeystarchikov]

Этим занимается Entity Framework

[AgentFire]

Но тогда индексация будет невозможна..

[mayorovp]

Почему вы думаете, что вот такой запрос будет выполнен без проблем с производительностью:

select * from Foo order by Bar

а вот такой уже не сможет использовать индексы?

select Extent1.Bar1 as Bar1, Extent1.Baz1 as Baz1
from (
    select Project1.Bar1 as Bar1, Project1.Baz1 as Baz1
    from (
        select Foo.Bar as Bar1, Foo.Bar as Baz1
        from Foo
    ) as Project1
    order by Project1.Bar
) as Extent1

[AgentFire]

У вас будет
не будет вложенного запроса с тем подходом, что описан в посте, пост вообще немного о другом, там будет
CASE WHEN Prop1 = Val1 THEN String1 CASE WHEN ... END
А это не индексируемо

[alexeystarchikov]

Индексация над проекцией в принципе невозможна.
Например, есть таблица USERS с ID, NAME, SURNAME.

SELECT NAME + ' ' + SURNAME FROM USERS

Какой тут индекс?

[AgentFire]

Вообще-то индексация вполне себе возможна над любой проекцией, в том числе и Automapper-овской, при выполнении определенного условия.
В случае с постом, если бы требовалась индексация, единственным верным решением было бы создавать отдельную таблицу на каждый Enum.

[alexeystarchikov]

Согласен. Но это уже будет не будет «не то». В таком случае, используя Automapper, в запрос будут добавлены `JOIN`.
Я говорил о том, что не получиться создать индекс для проекции, создаваемой «на лету». Если бы это был `VIEW, тогда да. Для вьюшек в MSSQL можно создать индексы. Но не для одного запроса

[AgentFire]

Если бы это был `VIEW, тогда да. Для вьюшек в MSSQL можно создать индексы. Но не для одного запроса

Не совсем ясен контекст вышего высказывания.
а) Индексировать VIEW можно только сделав его кластерным, и это уже не "на лету".
б) Так что ничто не мешает заранее проиндексировать стоблцы нужных таблиц для ожидаемого SELECT запроса "на лету".

[alexeystarchikov]

Возможно, пример неудачный привел.
В любом случае, мы явно отдалились от изначального вопроса.

[alexeystarchikov]

Если вы уже получили корректный IQueryable, т.е. когда как минимум можно получить данные через ToArray/ToList, значит запрос корректно транслируется в sql-запрос.
В данном случае, нужно помнить что тип данных результирующей колонки будет STRING. Поэтому при применении сортировки и фильтрации к этому полю, операции будут применяться к строковому результату, а не к исходному числовому enum.

[kemsky]

Неплохой вариант, но с другой стороны возникает вопрос, не лучше ли написать экстеншен метод т.е. foo.Enum.ToDisplayName()?

[alexeystarchikov]

В статье как раз есть такой хелпер EnumHelper.GetShortname
Но идея то не в этом, а в том, как эту операцию "отправить" в sql-запрос, чтобы не вытягивать из базы все записи, а потом маппить из поля

[kemsky]

Я имел ввиду, что может быть маппить и не нужно это поле вообще, а в месте использования просто использовать экстеншен метод: myLabel.Text = foo.Enum.ToDisplayName(). По скорости это будет не хуже (если использовать кэш имен), по удобству — терпимо.

[alexeystarchikov]

В конкретно взятом случае — да. Но если это веб-сервис, или вам нужно получить список сущностей с фильтрацией и сортировкой, то маппинг плохая идея. Тут нужно проекцией пользоваться

[alexeystarchikov]

Не совсем соглашусь с вами. То, что 0 соответствует строке «Any», а 1 — «Open» это никак не слой представления, это данные. 0 и 1 это идентификаторы. Строки — значения, им соответствующие.
Но наша идея интересная и имеет место быть.

Enum используется в проекте «исторически» и задача по стоит поддерживать чтение из существующей базы.

[alexeystarchikov]

Вот как раз 0 или 1.. Их заголовки это тоже данные, не имеющие отношение к данным. Но не будем спорить в этом русле, потому как и ваш вариант также укладывается в MVC. Я говорю немного о другом. Если заголовки enum относить к представлению, то получается, что одни и те же данные и бизнес платила для них будут находится на нескольких уровнях. И это главная проблема. Да, тут можно поспорить, "что есть представление", не отрицаю, тут ваши аргументы весомы. Но для чего обычно используется enum (точнее когда я его использую). Когда необходимо описать набор значений, от которых может зависеть бизнес-логика, когда это крайне неудобно представлять в виде отдельной таблицы в БД. Например, при описании набора состояний, особенной когда по условиям задачи, варианты состояний не меняются. Если это реализовать в виде таблицы, то в коде будет неявная свять, в виде "если Id=0, то вызываем какую то функцию". Поэтому и удобнее использовать enum. Это позволяет определить набор состояний, которые можно хранить в базе и которые однозначно определяются в коде. Но это пять же мое мнение.

[kemsky]

Пришлось отказаться - очень плохой запрос генерил ef6.