По dial-up соединению любой сайт будет открываться пол часа (: А если серьёзно, то нужно понимать область применеия Blazor - корпоративные приложения. А в этот сорфт работают с компа по проводному интернету и хорошо, если пользователи закрывают браузер и выключают компуктер раз в неделю, а не дожидаясь очередного обнолвнеия и неизбежной перезагрузки. Поэтому, размер приложения может быть как и 15МБ так 500Кб - пользователь разницы не заметит.
не используйте ORM для серьезных проектов. EF под.Net Core, кто придумал совместить отслеживание сущности с ее кэшированием? не хочешь кэширования (так как нужны актуальные данные) — надо писать AsNoTracking() — и как тогда сохранять (на этот механизм завязан и стейт)?
Чем вас ExecuteUpdate и ExecuteDelete не устраивают? В документации же всё написано.
Это очень сложно объяснить и мало у кого из них получается овладеть компетенциями иструментария иного рода для сужения "воронки" кандидатов. Ну а те что любят кари и какать на улице отличнл подоходят, как пример сравнения компетенций выходцев из этой страны с выходцами из европы или северной америки.
Спасибо за подсказку ещё одного варианта) Я нахожу её очень похожую на OneOf, но с один существенным преимуществом подписи методов выглядят как нативные типы C#. Из недостатков – всё тот же дополнительный метод Match вместо родного switch и принудительный деконструкции вариантов юниона по полям, и кодогенерация.
DU и подобные решения изобрели не вчера - такой подход уже очень давно существуют в функциональных языках, и даже относительно новый Rust использует DU :)
мы будем вынуждены пройтись по всему коду и добавить во все switch новую ветку
Вы не уловили суть такого подхода. Обрабатывать все варианты в каждом switch это и есть цель такого подхода.
Почему не использовать интерфейс или абстрактный класс с абстрактным методом?
Вы предлагаете отказаться от anemic model (только хранят данные), как в моих примерах, и перейти к reach model (моделям которых хранять своё состояние и имеют действия которые меняют это состояние). Или же путаете stateless services, которые не хранят данные, а только действия по преобразованию данных, и value types которые только хранять данные. В данных примерах BankAccount это анемичная модель.
Reach model это другой подход, более ООПшный, но уже редко используемый в современнои .NET. Хотя акторная модель, тот же Orleans может работать практически только с reach model.
Проблема в том, что никакой даты реализации DU даже и близко нет (: А StaticSc это буквально один аттрибут, а остальное - обычный C# с перебором производных типов в обычном switch. Даже если захотите от неё избавиться, то нужно всего лишь удалить [Closed] обычными средствами любого текстового редактора.
Интересно в каком таком случае нужно указывать явную загрузку файла конфигурации через .AddJsonFile()? Не проще ли сразу использовать ASP.NET Core и WebApplication, который сам поддятен все файлы конфигурации?
Хотя мне больше интересно как определение сложность поможет оценить скорость выполнения или затраты по мапяти, если детали реализации того или иного метода могут изменяться от версии к версии .NET, не считая использования векторизации в методах LINQ, которых прибавляется с каждой версией .NET?
Вы даже не представляете, что может твориться в западном стреднестатистическом не продуктовом энтерпрайзе...
Не очень давно была статья по внедрению Option Pattern в ASP.NET приложении, что вроде бы тоже азы (только уже фреймворка), но как показала практика даже люди с 10 годами опыта в программировании в солидных западных компаниях не знакомы не IOption не со способами их регистрации. Поэтому подобное и гораздо более «смешное» не то, что не может, а уже присутствует в кодовой базе довольно солидных корпорации.
Пятничный релиз для внутренних корпоративный приложений не то, что «нормально» явление, а часто единственно возможное решение, потому как пользователи на выходных и их работа ничем не прерывается. За пару дней можно выкатить и опробовать прод, может даже что-то пофиксить и избежать простоя целых отделов, работа которых суммарно дороже овертайма в выходные части команды разработки.
По dial-up соединению любой сайт будет открываться пол часа (:
А если серьёзно, то нужно понимать область применеия Blazor - корпоративные приложения. А в этот сорфт работают с компа по проводному интернету и хорошо, если пользователи закрывают браузер и выключают компуктер раз в неделю, а не дожидаясь очередного обнолвнеия и неизбежной перезагрузки. Поэтому, размер приложения может быть как и 15МБ так 500Кб - пользователь разницы не заметит.
Интересно как вы пришли к Visual Basic.NET в 2025 году?)
Вы имеет ввиду сущности (предметы), который и в реальном мире не изменяются со временем?
Чем вас ExecuteUpdate и ExecuteDelete не устраивают?
В документации же всё написано.
Это очень сложно объяснить и мало у кого из них получается овладеть компетенциями иструментария иного рода для сужения "воронки" кандидатов. Ну а те что любят кари и какать на улице отличнл подоходят, как пример сравнения компетенций выходцев из этой страны с выходцами из европы или северной америки.
Спасибо за подсказку ещё одного варианта)
Я нахожу её очень похожую на OneOf, но с один существенным преимуществом подписи методов выглядят как нативные типы C#.
Из недостатков – всё тот же дополнительный метод Match вместо родного switch и принудительный деконструкции вариантов юниона по полям, и кодогенерация.
Самый лучший вариант для Windows на сегодня для достижения лучшего UX и унификация технологий.
Ну хоть кто-то про акторы вспомнил (:
Эмм, и какие в нём дыры?
Вообще-то вы можете написать свою библиотеку анальтернативу OneOf, но вряди получится что-то более нативное и локаничное чем StaticSc.
DU и подобные решения изобрели не вчера - такой подход уже очень давно существуют в функциональных языках, и даже относительно новый Rust использует DU :)
Вы не уловили суть такого подхода. Обрабатывать все варианты в каждом switch это и есть цель такого подхода.
Вы предлагаете отказаться от anemic model (только хранят данные), как в моих примерах, и перейти к reach model (моделям которых хранять своё состояние и имеют действия которые меняют это состояние). Или же путаете stateless services, которые не хранят данные, а только действия по преобразованию данных, и value types которые только хранять данные. В данных примерах BankAccount это анемичная модель.
Reach model это другой подход, более ООПшный, но уже редко используемый в современнои .NET. Хотя акторная модель, тот же Orleans может работать практически только с reach model.
Проблема в том, что никакой даты реализации DU даже и близко нет (:
А StaticSc это буквально один аттрибут, а остальное - обычный C# с перебором производных типов в обычном switch. Даже если захотите от неё избавиться, то нужно всего лишь удалить [Closed] обычными средствами любого текстового редактора.
Зачем создавали кастомную очередь, при наличии Channels или ConcurrentQueue?
Интересно в каком таком случае нужно указывать явную загрузку файла конфигурации через
.AddJsonFile()? Не проще ли сразу использовать ASP.NET Core и WebApplication, который сам поддятен все файлы конфигурации?Хотя мне больше интересно как определение сложность поможет оценить скорость выполнения или затраты по мапяти, если детали реализации того или иного метода могут изменяться от версии к версии .NET, не считая использования векторизации в методах LINQ, которых прибавляется с каждой версией .NET?
А от чего не упомянули FrozenDictionary<TKey,TValue> и FrozenSet<T>? Они же созданные именно для поиска элементов.
Код и текст моего авторства. Текст изначально написан на английском и частично переведён на русский при помощи DeepL.
Тесты сломались, потому как в оригинальном маппере потерялся формат даты при парсинге. Заодно добавил тесты на мапперы со структурами.
Нет, такой цели никогда не было, проект был на ручномапперах. Да и кода меньше точно не будет и работать оно быстрее не станет.
Вы даже не представляете, что может твориться в западном стреднестатистическом не продуктовом энтерпрайзе...
Не очень давно была статья по внедрению Option Pattern в ASP.NET приложении, что вроде бы тоже азы (только уже фреймворка), но как показала практика даже люди с 10 годами опыта в программировании в солидных западных компаниях не знакомы не IOption не со способами их регистрации. Поэтому подобное и гораздо более «смешное» не то, что не может, а уже присутствует в кодовой базе довольно солидных корпорации.
Пятничный релиз для внутренних корпоративный приложений не то, что «нормально» явление, а часто единственно возможное решение, потому как пользователи на выходных и их работа ничем не прерывается. За пару дней можно выкатить и опробовать прод, может даже что-то пофиксить и избежать простоя целых отделов, работа которых суммарно дороже овертайма в выходные части команды разработки.