Ничто не идеально в нашем мире. Тут вы безусловно правы.
Но никто не говорил, что быть программистом легко. Хочешь, не хочешь а частности, которые нигде не используются, но они есть — придется выучить. С этим ничего не сделать, увы.
Вся прелесть заключается в том, что никто не запрещает пилить код на шарпе 10-летней давности (как и в случае с явой). И работать оно будет ничуть не хуже чем код обмазанный современным сахарком (а зачастую оно будет работать даже лучше, ибо никто по зиро кост абстракшн не упарывается).
Так что это не имеет значения. Порог входа в шарп останется тем же самым, что и 17 лет назад. А если какому-то джуниору придет в голову запихать ArrayList на прод, то ему очень быстро и доходчиво разьяснят, что время таких вещей безвозвратно ушло.
Я вас таки умоляю. Расскажите это создателям C# — который в принципе состоит из таких вещей, чуть менее, чем полностью. И ничего, все счастливы и требуют еще больше сахара!
PS: Нужно признать что там весь сахар органично накладывается на базу языка, а не как в случае с пхп8, но сам факт…
Вот только ветер дует не всегда в одну сторону и тем более не всегда в нужную. В Кении есть пассаты, они частично упрощают навигацию, но не делают ее настолько точной. Что происходит когда шарик относит километров на 10-20 от намеченной позиции, а попутного ветра нет?
А как они решили проблему удержания шаров над небольшой в общем то территорией? На высоте в 20км ветры под 80-100км/ч дуют. Еще и навигацию реализовали…
Сам ввод пароля плохая идея — он подразумевает что-то скрывают.
Лучше сделать так — по умолчанию всегда открывается фейковый аккаунт, а для того чтобы перейти в реальный нужно, например, нарисовать какую нибудь фигуру на экране (причем можно завести несколько аккаунтов для нескольких фигур) — прямо в открытом приложении. Ну или трижды-четырежды тапнуть по какому нибудь обычному элементу/кнопке, например по настройкам.
Чисто теоретически можно злоупотребить такой уязвимостью и заабузить какой нибудь политический проамериканский канал (исключительно в просветительских целях). Вопрос не прилетит ли ответка? Наши любят прогибаться под американские корпорации…
Тут надо измерять, но в случае с DynamicObject мы подключаем целый рантайм, который берет на себя многие вещи, в том числе и кэширование.
Т.е. первый вызов TryGetMember для каждого из параметров будет очень медленным, но потом будет использоваться уже закэшированная версия. По сути, тот же финт ушами, что и с заранее скомпилированной лямбдой для рефлексии, только автоматически и без рефлексии.
Но главная фишка не в этом. А в более гибком подходе, например, мы можем загрузить все исходные данные в список, потом сделать выборку и отрефлексить только нужные данные.
Этот подход не лучше и не хуже, описанного в статье, но именно на данном классе задач, динамика дает довольно большое преимущество перед статикой опирающейся на отражение.
Вы абсолютно правы. Мой изначальный комментарий относился не к сути статьи.
А к тому что подобные задачи можно решать эффективнее, за счет использования динамики. Несмотря на свою неспешность, DLR все еще производительнее рефлексии.
Набросал небольшой прототип. В кратце, для данного типа задач, если использовать динамику — рефлексия вовсе не нужна и производительность будет упираться в скорость парсера и эффективность алгоритма сопоставления псевдонимов.
Собственно исходник
За основу взят ваш код, только Autofac заменен родным Core DI, а вместо моков используется InMemoryDatabase.
Да тут проблема «слишком общего вопроса». Каждый из пунктов требует уточнения, либо на уровне источников, как с паттернами (ну нет строгого разделения между архитектурой и проектированием, а в разных книжках запросто могут отнести один и тот же паттерн к разным сущностям), либо на уровне конкретной технологии, как с 4м вопросом. Например в .net — под этим вопросом можно подразумевать как pipeline обработки запроса внутри asp.net, так и более общий случай обработки внутри IIS или Kestrel (или обоих сразу, такое тоже встречается).
Так что такой набор вопросов — это признак эникейщика загуглившего популярные вопросы, технари спрашивают, как правило, конкретику.
Но никто не говорил, что быть программистом легко. Хочешь, не хочешь а частности, которые нигде не используются, но они есть — придется выучить. С этим ничего не сделать, увы.
Но это приходит потом. Совсем потом.
Так что это не имеет значения. Порог входа в шарп останется тем же самым, что и 17 лет назад. А если какому-то джуниору придет в голову запихать ArrayList на прод, то ему очень быстро и доходчиво разьяснят, что время таких вещей безвозвратно ушло.
PS: Нужно признать что там весь сахар органично накладывается на базу языка, а не как в случае с пхп8, но сам факт…
Вот только ветер дует не всегда в одну сторону и тем более не всегда в нужную. В Кении есть пассаты, они частично упрощают навигацию, но не делают ее настолько точной. Что происходит когда шарик относит километров на 10-20 от намеченной позиции, а попутного ветра нет?
Лучше сделать так — по умолчанию всегда открывается фейковый аккаунт, а для того чтобы перейти в реальный нужно, например, нарисовать какую нибудь фигуру на экране (причем можно завести несколько аккаунтов для нескольких фигур) — прямо в открытом приложении. Ну или трижды-четырежды тапнуть по какому нибудь обычному элементу/кнопке, например по настройкам.
Без нормальных сеньоров далеко они не уедут… И похоже это становится все более очевидным даже людям со стороны.
Т.е. первый вызов TryGetMember для каждого из параметров будет очень медленным, но потом будет использоваться уже закэшированная версия. По сути, тот же финт ушами, что и с заранее скомпилированной лямбдой для рефлексии, только автоматически и без рефлексии.
Но главная фишка не в этом. А в более гибком подходе, например, мы можем загрузить все исходные данные в список, потом сделать выборку и отрефлексить только нужные данные.
Этот подход не лучше и не хуже, описанного в статье, но именно на данном классе задач, динамика дает довольно большое преимущество перед статикой опирающейся на отражение.
А к тому что подобные задачи можно решать эффективнее, за счет использования динамики. Несмотря на свою неспешность, DLR все еще производительнее рефлексии.
Собственно исходник
За основу взят ваш код, только Autofac заменен родным Core DI, а вместо моков используется InMemoryDatabase.
Так что такой набор вопросов — это признак эникейщика загуглившего популярные вопросы, технари спрашивают, как правило, конкретику.