All streams
Search
Write a publication
Pull to refresh
3
0

Разработчик

Send message

но позвольте! а как вы раньше писали код, серьезно не задумываясь о том, что, в какой то конкретный момент, вот в этом вот месте, вы планируете возвращать null, и что вызывающий код должен сделать соответсвующую проверку? или вы просто по дефолту везде ThrowIfNull писали?


а что же касается "огромного количество фреймворков", то здесь ожидается полезность фунции только если конкретный фреймворк использовал это нововведение. скорее всего, MS введет атрибут [DontCheckForNullables] для референсов разных DLL.

надеюсь они уберут этот бесполезный функционал

где нужно ставить “?”, а где не нужно, зачастую очень сложно.

как это так? объясните. имхо, это же очень просто

интересно в каком языке все таки сделали полное математическое описание, с круглыми и квадратными скобками?

Парадигма CQRS в том или ином виде предполагает, что вызовы Query не будут менять состояние приложения. То есть многократные вызовы одной и той же query, в рамках одного запроса, будут иметь один и тот же результат.

НЕЕЕЕ, НУ ТАК НЕ ИНТЕРЕСНО....

он в принципе не умеет работать с string.Format. а это именно то, во что разворачивается интерполирование.

штатный провайдер просто не умеет конвертировать вызовы к Format в нужную форму для обращения к БД

Ого, наконец-то годная статейка.


Надо полагать, автор заодно захочет похвастаться знанием, как переопределить штатный QueryProvider у старого доброго Linq-2-Sql? Чтобы это добро все у меня заработало из коробки.

И почему это плохо, иметь статичный, доступный отовсюду некий GameState?

эм, но в таком случае в статик кладется объект а-ля AllStaticData и обнуляется только он.

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

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

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

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

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

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

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

я смотрю у вас комментарии не сильно отличаются друг от друга-то.

а в чем прекол?
а, я понял, вы на асме наверное пишите

не понял, голый SQL?

Information

Rating
Does not participate
Registered
Activity