В своих проектах всё, что можно провалидировать атрибутами, валидирую атрибутами. От этого особенно выигрывают проекты на Blazor, т.к. там это работает, как на сервере, так и на клиенте.
Я не вижу ни одного реального примера, для которого может понадобиться обязательно указывать null для nullable. Допустим, сделали неявное явным, но как это поможет? На мой взгляд это лишь загромождает код. Если в дальнейшем коде устраивает значение по умолчанию, то модификатор required не нужен.
Для других типов я предпочитаю использовать более конкретные атрибуты, вроде Range или прочие самописные (например, IsPositive). А для более сложных валидаций пишу валидаторы, которые заполняют ModelState ошибками.
Однажды меня попросили научить программированию и я решил, что это отличная идея. Ещё до самого языка пришлось объяснять, что такое консольные приложения и зачем они вообще нужны. Так что программирование начинается не с кода.
А за актуальным гайдом по C# уже много лет всех отправляю сюда от ребят из "Контура".
Зачем начинающему показывать Main(), если уже можно не показывать? Чем меньше нагружать грудой слов со старта, тем легче пойдёт. А про Main() и чуть позже можно разжевать.
Это же сколько незнакомых слов со старта: using, System, class, Program, static, void, Main - до которых ещё долго и сразу все не объяснить, не напугав.
Причём далеко ходить не надо. При открытии Хабра на телефоне, где нет безлимитного траффика, легко могут сожраться драгоценные 100 МБ. А я просто статью хотел почитать, в которой даже картинок нет.
Подумаешь, ошибка на процент. Какая разница, телепортирует вас в соседнюю комнату или в стену между ними. Главное, что тело хотя бы в границы атмосферы Земли окажется.
Поражаюсь фантазии автора. Смотрю на все эти 100500 спиралей, нарисованных поверх картинок и ума не приложу, откуда автор их там взял. А я раньше думал, что у меня фантазия хорошая.
Но даже в этой теории появилась своя "тёмная материя", чтобы удержать её на плаву. Галактика постепенно лишается вещества, но оно восполняется откуда-то извне, причём, похоже, в тех же объёмах. Как, интересно, учёные не заметили летающие где-то неподалёку за пределами галактик миллиарды остывших звёзд и планет? И как они не заметили колоссальный приток частиц (причём, похоже, все летят в центр), компенсирующий это настолько, что за 13,6 млрд лет Млечный путь всё ещё полон звёзд ближе к центру, а не превратился в узкое кольцо доживающих свою жизнь звёзд.
Один из своих сайтов я сначала таким образом написал. Он работал существенно медленнее переделанной версии и при потере подключения приходилось перезагружать страницу. Особенно неудобно было пользоваться с телефона.
Blazor - офигенная штука! Можно писать фронт так, будто пишешь бэк. Все боли фронтендеров фактически отсутствуют, при особом желании можно даже совсем без JS обойтись. Имеются разные варианты использования Blazor:
С постоянным подключением к серверу - довольно медленное решение, но можно быстро написать всё в одном. Можно писать запросы к БД хоть прямо со страницы.
Только фронт с отдельным API (на чём угодно). Очень быстро работает, максимально простое решение, рендеринг на клиенте. Можно получить данные при инициализации страницы. Фактически не отличается от MVC, если API на C#.
Связка фронта и API с возможностью рендеринга на сервере. Тут надо сначала поразбираться, данные можно получать в разных местах в зависимости от выбранного режима рендеринга. Самое сложное решение, но при этом самое гибкое, с кучей возможностей. Не требует постоянного соединения с сервером.
Я использовал все три подхода. В новом проекте собираюсь использовать третий. Для меня даже нет варианта выбора другого фреймворка. Blazor почти идеален.
А ещё там встроены страницы управления аккаунтом. Так что можно с ходу иметь сайт с возможностью регистрации пользователей, не тратя на это кучу времени. Остаётся лишь настроить под себя.
Да, это самое бесячее в SQL. Сам хотел оставить подобный комментарий. Стоит только внести изменения вроде переименования поля, как надо потом по всему коду искать, где это используется. С ORM достаточно просто переименовать поле и обновить БД.
В своих проектах всё, что можно провалидировать атрибутами, валидирую атрибутами. От этого особенно выигрывают проекты на Blazor, т.к. там это работает, как на сервере, так и на клиенте.
Я не вижу ни одного реального примера, для которого может понадобиться обязательно указывать
nullдляnullable. Допустим, сделали неявное явным, но как это поможет? На мой взгляд это лишь загромождает код. Если в дальнейшем коде устраивает значение по умолчанию, то модификаторrequiredне нужен.Продажа и маркетинг - просто главная боль! Есть продукт, но трудно без этого привести пользователей.
Для других типов я предпочитаю использовать более конкретные атрибуты, вроде
Rangeили прочие самописные (например,IsPositive). А для более сложных валидаций пишу валидаторы, которые заполняютModelStateошибками.Однажды меня попросили научить программированию и я решил, что это отличная идея. Ещё до самого языка пришлось объяснять, что такое консольные приложения и зачем они вообще нужны. Так что программирование начинается не с кода.
А за актуальным гайдом по C# уже много лет всех отправляю сюда от ребят из "Контура".
Зачем начинающему показывать
Main(), если уже можно не показывать? Чем меньше нагружать грудой слов со старта, тем легче пойдёт. А проMain()и чуть позже можно разжевать.Это же сколько незнакомых слов со старта:
using,System,class,Program,static,void,Main- до которых ещё долго и сразу все не объяснить, не напугав.Ядрёна кочерыжка! Вам не нравится отсутствие мата в моей речи? Вы хотите поговорить об этом?
Причём далеко ходить не надо. При открытии Хабра на телефоне, где нет безлимитного траффика, легко могут сожраться драгоценные 100 МБ. А я просто статью хотел почитать, в которой даже картинок нет.
Подумаешь, ошибка на процент. Какая разница, телепортирует вас в соседнюю комнату или в стену между ними. Главное, что тело хотя бы в границы атмосферы Земли окажется.
Поражаюсь фантазии автора. Смотрю на все эти 100500 спиралей, нарисованных поверх картинок и ума не приложу, откуда автор их там взял. А я раньше думал, что у меня фантазия хорошая.
Но даже в этой теории появилась своя "тёмная материя", чтобы удержать её на плаву. Галактика постепенно лишается вещества, но оно восполняется откуда-то извне, причём, похоже, в тех же объёмах. Как, интересно, учёные не заметили летающие где-то неподалёку за пределами галактик миллиарды остывших звёзд и планет? И как они не заметили колоссальный приток частиц (причём, похоже, все летят в центр), компенсирующий это настолько, что за 13,6 млрд лет Млечный путь всё ещё полон звёзд ближе к центру, а не превратился в узкое кольцо доживающих свою жизнь звёзд.
Perplexity туда же и Claude. Так что сейчас для Gemini настал звёздный час.
Один из своих сайтов я сначала таким образом написал. Он работал существенно медленнее переделанной версии и при потере подключения приходилось перезагружать страницу. Особенно неудобно было пользоваться с телефона.
Blazor - офигенная штука! Можно писать фронт так, будто пишешь бэк. Все боли фронтендеров фактически отсутствуют, при особом желании можно даже совсем без JS обойтись. Имеются разные варианты использования Blazor:
С постоянным подключением к серверу - довольно медленное решение, но можно быстро написать всё в одном. Можно писать запросы к БД хоть прямо со страницы.
Только фронт с отдельным API (на чём угодно). Очень быстро работает, максимально простое решение, рендеринг на клиенте. Можно получить данные при инициализации страницы. Фактически не отличается от MVC, если API на C#.
Связка фронта и API с возможностью рендеринга на сервере. Тут надо сначала поразбираться, данные можно получать в разных местах в зависимости от выбранного режима рендеринга. Самое сложное решение, но при этом самое гибкое, с кучей возможностей. Не требует постоянного соединения с сервером.
Я использовал все три подхода. В новом проекте собираюсь использовать третий. Для меня даже нет варианта выбора другого фреймворка. Blazor почти идеален.
А ещё там встроены страницы управления аккаунтом. Так что можно с ходу иметь сайт с возможностью регистрации пользователей, не тратя на это кучу времени. Остаётся лишь настроить под себя.
Некоторые ORM вообще позволяют и SQL отправить, и работать с результатом привычным для ORM удобным образом.
Да, это самое бесячее в SQL. Сам хотел оставить подобный комментарий.
Стоит только внести изменения вроде переименования поля, как надо потом по всему коду искать, где это используется. С ORM достаточно просто переименовать поле и обновить БД.
Отскоков к прежним значениям обычно не бывает.
Hacker News, видимо.
Люди давно задаются такими вопросами. Даже тут.
https://habr.com/en/articles/58714/
https://qna.habr.com/q/10486
https://qna.habr.com/q/662787
https://qna.habr.com/q/11520
Обратил внимание, что миллионы как-то пропали с 2014. Может, случилось чего тогда?
Ах, точно. Geektimes появился.
В мире, где на работу нанимают не только программистов, но и, например, воспитателей детсадов, это очень даже важно.