но позвольте! а как вы раньше писали код, серьезно не задумываясь о том, что, в какой то конкретный момент, вот в этом вот месте, вы планируете возвращать null, и что вызывающий код должен сделать соответсвующую проверку? или вы просто по дефолту везде ThrowIfNull писали?
а что же касается "огромного количество фреймворков", то здесь ожидается полезность фунции только если конкретный фреймворк использовал это нововведение. скорее всего, MS введет атрибут [DontCheckForNullables] для референсов разных DLL.
Парадигма CQRS в том или ином виде предполагает, что вызовы Query не будут менять состояние приложения. То есть многократные вызовы одной и той же query, в рамках одного запроса, будут иметь один и тот же результат.
Надо полагать, автор заодно захочет похвастаться знанием, как переопределить штатный QueryProvider у старого доброго Linq-2-Sql? Чтобы это добро все у меня заработало из коробки.
Если бы это был `VIEW, тогда да. Для вьюшек в MSSQL можно создать индексы. Но не для одного запроса
Не совсем ясен контекст вышего высказывания.
а) Индексировать VIEW можно только сделав его кластерным, и это уже не "на лету".
б) Так что ничто не мешает заранее проиндексировать стоблцы нужных таблиц для ожидаемого SELECT запроса "на лету".
Вообще-то индексация вполне себе возможна над любой проекцией, в том числе и Automapper-овской, при выполнении определенного условия.
В случае с постом, если бы требовалась индексация, единственным верным решением было бы создавать отдельную таблицу на каждый Enum.
У вас будет
не будет вложенного запроса с тем подходом, что описан в посте, пост вообще немного о другом, там будет CASE WHEN Prop1 = Val1 THEN String1 CASE WHEN ... END
А это не индексируемо
А как дела обстоят с сортировкой и фильтрацией на конечном потребителе?
Что, если полученный IQueryable требуется передать дальше по логической цепочке, где будут применены Where/OrderBy и т.п.?
но позвольте! а как вы раньше писали код, серьезно не задумываясь о том, что, в какой то конкретный момент, вот в этом вот месте, вы планируете возвращать null, и что вызывающий код должен сделать соответсвующую проверку? или вы просто по дефолту везде ThrowIfNull писали?
а что же касается "огромного количество фреймворков", то здесь ожидается полезность фунции только если конкретный фреймворк использовал это нововведение. скорее всего, MS введет атрибут [DontCheckForNullables] для референсов разных DLL.
надеюсь они уберут этот бесполезный функционал
как это так? объясните. имхо, это же очень просто
интересно в каком языке все таки сделали полное математическое описание, с круглыми и квадратными скобками?
НЕЕЕЕ, НУ ТАК НЕ ИНТЕРЕСНО....
пожалуйста, будьте добры.
он в принципе не умеет работать с string.Format. а это именно то, во что разворачивается интерполирование.
штатный провайдер просто не умеет конвертировать вызовы к Format в нужную форму для обращения к БД
Ого, наконец-то годная статейка.
Надо полагать, автор заодно захочет похвастаться знанием, как переопределить штатный QueryProvider у старого доброго Linq-2-Sql? Чтобы это добро все у меня заработало из коробки.
И почему это плохо, иметь статичный, доступный отовсюду некий
GameState
?эм, но в таком случае в статик кладется объект а-ля
AllStaticData
и обнуляется только он.Не совсем ясен контекст вышего высказывания.
а) Индексировать VIEW можно только сделав его кластерным, и это уже не "на лету".
б) Так что ничто не мешает заранее проиндексировать стоблцы нужных таблиц для ожидаемого SELECT запроса "на лету".
Вообще-то индексация вполне себе возможна над любой проекцией, в том числе и Automapper-овской, при выполнении определенного условия.
В случае с постом, если бы требовалась индексация, единственным верным решением было бы создавать отдельную таблицу на каждый Enum.
У вас будет
не будет вложенного запроса с тем подходом, что описан в посте, пост вообще немного о другом, там будет
CASE WHEN Prop1 = Val1 THEN String1 CASE WHEN ... END
А это не индексируемо
Но тогда индексация будет невозможна..
Но каким же образом они транслируются в SQL?
А как дела обстоят с сортировкой и фильтрацией на конечном потребителе?
Что, если полученный IQueryable требуется передать дальше по логической цепочке, где будут применены Where/OrderBy и т.п.?
я смотрю у вас комментарии не сильно отличаются друг от друга-то.
а в чем прекол?
а, я понял, вы на асме наверное пишите
не понял, голый SQL?