Comments 25
Automapper плох тем, что его автор очень часто делает ломающие изменения.
Как написали на иностранном форуме «Похоже его разработчик сидит на тяжелых наркотиках»
Как только что-то начнете использовать отличное от тривиального маппинга — то скорее всего будет тяжело обновиться на следующую версию.
А как дела обстоят с сортировкой и фильтрацией на конечном потребителе?
Что, если полученный IQueryable требуется передать дальше по логической цепочке, где будут применены Where/OrderBy и т.п.?
Но каким же образом они транслируются в SQL?
Но тогда индексация будет невозможна..
Почему вы думаете, что вот такой запрос будет выполнен без проблем с производительностью:
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Индексация над проекцией в принципе невозможна.
Например, есть таблица USERS с ID, NAME, SURNAME.
SELECT NAME + ' ' + SURNAME FROM USERSКакой тут индекс?
Вообще-то индексация вполне себе возможна над любой проекцией, в том числе и Automapper-овской, при выполнении определенного условия.
В случае с постом, если бы требовалась индексация, единственным верным решением было бы создавать отдельную таблицу на каждый Enum.
Я говорил о том, что не получиться создать индекс для проекции, создаваемой «на лету». Если бы это был `VIEW, тогда да. Для вьюшек в MSSQL можно создать индексы. Но не для одного запроса
Если бы это был `VIEW, тогда да. Для вьюшек в MSSQL можно создать индексы. Но не для одного запроса
Не совсем ясен контекст вышего высказывания.
а) Индексировать VIEW можно только сделав его кластерным, и это уже не "на лету".
б) Так что ничто не мешает заранее проиндексировать стоблцы нужных таблиц для ожидаемого SELECT запроса "на лету".
Если вы уже получили корректный IQueryable, т.е. когда как минимум можно получить данные через ToArray/ToList, значит запрос корректно транслируется в sql-запрос.
В данном случае, нужно помнить что тип данных результирующей колонки будет STRING. Поэтому при применении сортировки и фильтрации к этому полю, операции будут применяться к строковому результату, а не к исходному числовому enum.
Неплохой вариант, но с другой стороны возникает вопрос, не лучше ли написать экстеншен метод т.е. foo.Enum.ToDisplayName()?
В статье как раз есть такой хелпер EnumHelper.GetShortname
Но идея то не в этом, а в том, как эту операцию "отправить" в sql-запрос, чтобы не вытягивать из базы все записи, а потом маппить из поля
Но наша идея интересная и имеет место быть.
Enum используется в проекте «исторически» и задача по стоит поддерживать чтение из существующей базы.
Вот как раз 0 или 1.. Их заголовки это тоже данные, не имеющие отношение к данным. Но не будем спорить в этом русле, потому как и ваш вариант также укладывается в MVC. Я говорю немного о другом. Если заголовки enum относить к представлению, то получается, что одни и те же данные и бизнес платила для них будут находится на нескольких уровнях. И это главная проблема. Да, тут можно поспорить, "что есть представление", не отрицаю, тут ваши аргументы весомы. Но для чего обычно используется enum (точнее когда я его использую). Когда необходимо описать набор значений, от которых может зависеть бизнес-логика, когда это крайне неудобно представлять в виде отдельной таблицы в БД. Например, при описании набора состояний, особенной когда по условиям задачи, варианты состояний не меняются. Если это реализовать в виде таблицы, то в коде будет неявная свять, в виде "если Id=0, то вызываем какую то функцию". Поэтому и удобнее использовать enum. Это позволяет определить набор состояний, которые можно хранить в базе и которые однозначно определяются в коде. Но это пять же мое мнение.
Пришлось отказаться - очень плохой запрос генерил ef6.
Получаем данные enum в проекции Automapper