Сломается одна зависимость и сломаются все endpoint, которые находятся в контроллере.
Обычно зависимости идут не в контроллеры, а хэндлеры/сервисы (впрочем, в случае сервисов, проблема остается но просто в другом слое). Но, если хочется в контроллер - DI там тоже работает не только в конструкторе контроллера, но и в его методах (эндпоинтах), и можно прокинуть сервис туда. Я, поэтому, не упомянул в плюсах Minimal API то что мы тащим только нужные для конкретного эндпоинта сервисы: в контроллерах так тоже можно.
Обвязка для регистрации? Ну, это десяток строк кода, плюс по 1 строчке на эндпоинт/группу эндпоинтов.
А если остальное так у нас как были, так и есть много коробочных фильтров/middleware/поддержка OpenAPI от Microsoft. Просто, в большом проекте (а я в статье делаю акцент на такой), всегда появятся свои приколы, и тут уж, не важно какой язык, фреймворк или библиотека - за вас это никто не напишет.
Спасибо, поправил про метадату. Что-то в моей голове заставило меня думать (видимо потому что везде видел MethodInfo), что она появилась только с Minimal API. Ссылку на цикл статей тоже добавил.
Тут с автором еще можно поспорить с его "делаем в HandleAsync всю работу", но это уже оффтоп.
Ну это, как я написал, с примером из моей статьи про VSA. Тут просто для наглядности, каким-нибудь MediatR, валидаторами или репозиториями, как раньше, никто пользоваться не запрещает.
Как можно посмотреть в eShop, похожий подход теперь самими Microsoft одобрен =)
Ну, никто не запрещает так делать (сами Microsoft по сути раньше так и делали), так что вопрос тут скорее о мнениях. (Если, конечно, не нужна гибкость, которую дает ручная регистрация: навешивать метадату на группы эндпоинтов, разбивать эндпоинты по проектам, подключать только часть из них, и т.п. - но это штуки ситуативные и не то чтобы совсем с автоматической регистрацией не совместимы.)
С моей точки зрения, в контроллерах это - задокументированная фича фреймворка, о которой разработчик узнает на этапе "пишем hello world", поэтому там такой подход логичен. В эндпоинтах же - это перемещается на уровень соглашений в проекте.
нормально продумаете и документируете для своего проекта
Уже проблема: к сожалению, нормально задокументированный проект - это скорее редкость, чем норма. И, даже если хорошая документация есть, это дополнительное время на прочтение, усваивание инфы.
И если у нас в проекте одно такое исключение, для эндпоинтов - ничего страшного, правда. Но, идут годы, проект растет, таких исключений уже куча. Вы так не планировали? Ну так другой разработчик подумал, раз есть одно, то почему бы и не два. А вы были в отпуске, или PR прошел мимо вас. А теперь это задача на рефакторинг, на которую менеджер не дает времени, потому что "что нам это даст?", и т.п. И вот уже незаметненько, новые разработчики сидят и по несколько месяцев онбордятся, пытаясь разобраться что тут происходит. Еще и без возможности пройтись по всей цепочке Usages и отследить, потому что цепочки разорваны рефлексией.
А ведь есть неплохое правило "хороший код должен сам себя документировать". Конечно, его не везде получится соблюсти, но зачем просто так его нарушать.
Избавление от рефлексии целиком и переход на NativeAOT в большом проекте - это тема для отдельной статьи, и переход на Minimal API тут был бы лишь один из шагов. У меня тут меньше опыта, поэтому сразу и то и то я делать не пытался. Да и, многим сейчас NuGet-зависимости не позволят, которые еще не стать совместимыми. Но, пара моментов:
Json source generators опционально есть, вот пример для Minimal API. В идеале конечно, да, надо бы их использовать. MethodInfo я там, если посмотрите, парой абзацев ниже как раз показал на что заменить.
EF тоже может работать c Native AOT. Правда, с заметными ограничениями, и в целом, выстрелить себе в колено стало еще проще. Зато с такими ограничениями разница в производительности "в среднем" между EF и raw sql, которая и так стремительно уменьшается последние годы, еще меньше. В общем, вкусовщина
"Поиске" - я имею ввиду как у контроллеров, автоматического. Для регистрации эндпоинтов из моей статьи это выглядело бы приблизительно так:
var endpoints = Assembly.GetExecutingAssembly().DefinedTypes
.Where(type => type is { IsClass: true, IsAbstract: false } && typeof(IEndpoint).IsAssignableFrom(type));
Заглянул под капот контроллеров, там примерно тот же принцип в чуть более красивой обертке. И, ничто не мешает так сделать для эндпоинтов. И разные сервисы для DI подхватывать например, или что еще вам нужно. Красиво - просто написал условный Handler для MediatR, а он автоматом уже зарегистрирован, никаких "опять забыл в DI прокинуть".
Вот только, злоупотребление такой черной магией несет за собой негативные последствия: меньшую гибкость, усложнение восприятия для новых разработчиков (в т.ч. разрыв цепочки usage, не проследишь что откуда вызывается). И старых, когда все нюансы работы проекта начнут забываться, и рефлексию, от которой стараемся избавиться Стоит ли того 1 сэкономленная строчка кода на эндпоинт/сервис? Microsoft вот раньше, с контроллерами, считали, что можно сделать исключение. Сейчас, не безосновательно, они так не делают
По слою UI на картинке проведен слайс, да. Но это не значит, что за один слайс будет отвечать сверху до низу один человек. Кто-то может писать БД часть, кто-то UI. На практике фронт часто отделен от бэка совсем, и там может быть вообще своя архитектура и бэкендеру об этом думать не нужно - все варьируется от проекта к проекту. Но на бэке, вряд ли у вас будет что-то типа "я пишу DTO для этого эндпоинта, ты - преобразование моделей БД в DTO, а вот он - валидацию", условно говоря. Этим, как правило занимается один человек, в рамках одной задачи. Отсюда и логика архитектуры.
Но вот в целом, (прошу прощения если ошибаюсь), вы уже пытаетесь рассуждать нетривиальными абстракциями, имея довольно небольшие представления о том, как это все работает на практике. И проблема тут не в вас: я тонкой нитью по статье провожу, что, по моему мнению, мы слишком усложняем проекты и строим лишние абстракции там, где это не нужно. Что приводит к тому, что нам повально нужны сеньоры, которые смогут во всем этом добре разобраться. А VSA - пример того, как упростить это дело. Я как-то видел проект, где ребята пытались строить CQRS, DDD и чистую архитектуру, пока в самом проекте было полно веселья типа эндпоинтов, возвращающих статус 200 с ошибкой внутри.
Да, VSA в текущем виде - не универсальное решение, хотя у меня есть подозрение что универсального решения и не будет: слишком уж размыты могут быть границы фичи от проекта к проекту. Да и сегодня твой эндпоинт рекомендаций для юзера учитывает только его купленные товары, а завтра пол базы корми нейронке, чтобы угадывать что захочет купить юзер. В общем, правила может и можно сформулировать, только увы, головой все равно думать придется.
Но с LLM-ками да. По моему опыту, они могут подсказывать куда чаще и качественнее с VSA структурой (да и просто если писать код не забывая о KISS), чем с огородом из слоев и абстракций, даже при одинаковом функционале проекта.
=) Все мы иногда тупни. Найти себе сплошных senior-ninja-10+yoe-developer в команду, чтобы поддерживать сложную архитектуру, и не испортить все в первый кранч/отпуск тимлида (и это еще если тимлид сам понимает, что делает) - это, конечно, здорово, но сложно и дорого.
Можно найти довольно много книг/статей, и вот прям шаг за шагом построить себе красивую архитектуру следуя всем заветам, и для этого не потребуется быть каким-то одаренным разработчиком. Однако, точно ли оно стоило потраченного времени? Точно ли бизнес выиграет от этого оверхэда? Точно ли коллега прочел ту же книгу и на одной волне с тобой, или просто делает вид? На разных проектах свои правильные ответы на эти вопросы, но у меня есть ощущение, что к сожалению их обычно не задают себе.
Я там местами описал, в параграфах про DDD и границы подхода: далеко не весь код проекта получится (и стоит) поделить прям по слайсам: горизонтальные слои все равно останутся, и для меня суть VSA скорее в том, чтобы избавиться от горизонтальных слоев (и не размазывать код по всему проекту) там, где это возможно. Так что, возможно, корректнее это было бы назвать VSA+HSA. Но если ваше понимание этого отличается, то интересно было бы услышать.
Умели диагностировать — это одно. А вот если диагностировали повсеместно и так же верно — это другое. Потому что так уже где-то однажды чуть не доказали то, что телефоны (или что там было) вызывают рак, не учтя, что раньше его плохо диагностировали.
Ну да, РКН может хоть завтра запросить переписку тех же условных террористов с питерского метро, но будет послан далеко и надолго, а никакие бумажки и близко подойти к серверам им не позволят. Запросят ли подобное? Вопрос времени я считаю. Но Дуров в любом случае без каких либо последствий для репутации телеграма отсрочил его блокировку.
Звучит как прекрасная идея для новой блокировки!
Не ну а что, оставят игры мейл ру, и все будут довольны. Кроме пользователей, но кому до них какое дело тут?
Ну на самом деле запрашиваемая информация весьма безобидна, так что некоторая логика все же есть.
Другое дело, правда, что ее предоставление лишь ненадолго отсрочит неизбежное: сегодня информацию о компании, а завтра ключи шифрования.
Жаль, конечно, столь удобный мессенджер для работы терять, думаю возиться с обходом блокировок далеко не все захотят, но лучше уж так чем прогибаться, тут согласен.
Может и будет, а может и нет. Однако мы точно знаем что представляет из себя текущая власть сейчас — и темная лошадка кажется совсем неплохой альтернативой.
CPU потихоньку начинают чувствовать потолок сверху. Частоты выше 4-5ггц даются с трудом, а наращивать количество ядер в не серверных CPU дело сомнительное (что подтверждают последние архитектуры AMD до Ryzen). Можно было бы и 16-ядерные варианты выпускать, но зачем? То, что хорошо распараллеливается на десктопах переносится на GPU.
Плюс последние годы AMD не могли нормально конкурировать с Intel в средне-высоком ценовом сегменте после того, как у последних получились очень удачные i3/5/7. И в то время как упустил годик на рынке GPU — потерял приличную аудиторию, то на рынке CPU Intel могла себе позволить несколько лет выпускать минорные апдейты: AMD все равно отстает плюс у старых процессоров все хорошо с производительностью.
Грустный обзор: ничего интересного не сказано. Такой можно было бы написать просто повертев этот шлем в руках пару минут. Если конкретно, то претензии:
— Почему он назван новым Gear VR? Это как назвать HTC Vive новой версией Oculus Rift. Этот шлем скорее ответ на Google Daydream.
— Сравнения с другими VR шлемами нет.
— Где нормальный обзор доступных приложений, а не просто ссылка на форум?
— О пульте управления написано одно предложение: он есть.
— О линзах тоже почти ничего. А их качество важно.
Я, конечно, все понимаю реклама товара который у вас есть, но с такими статьями хабр в сполшую рекламу в статьях скатится
Ну, справедливости ради
Обычно зависимости идут не в контроллеры, а хэндлеры/сервисы (впрочем, в случае сервисов, проблема остается но просто в другом слое).
Но, если хочется в контроллер - DI там тоже работает не только в конструкторе контроллера, но и в его методах (эндпоинтах), и можно прокинуть сервис туда.
Я, поэтому, не упомянул в плюсах Minimal API то что мы тащим только нужные для конкретного эндпоинта сервисы: в контроллерах так тоже можно.
Обвязка для регистрации? Ну, это десяток строк кода, плюс по 1 строчке на эндпоинт/группу эндпоинтов.
А если остальное так у нас как были, так и есть много коробочных фильтров/middleware/поддержка OpenAPI от Microsoft. Просто, в большом проекте (а я в статье делаю акцент на такой), всегда появятся свои приколы, и тут уж, не важно какой язык, фреймворк или библиотека - за вас это никто не напишет.
Спасибо, поправил про метадату. Что-то в моей голове заставило меня думать (видимо потому что везде видел MethodInfo), что она появилась только с Minimal API.
Ссылку на цикл статей тоже добавил.
Ну это, как я написал, с примером из моей статьи про VSA. Тут просто для наглядности, каким-нибудь MediatR, валидаторами или репозиториями, как раньше, никто пользоваться не запрещает.
Как можно посмотреть в eShop, похожий подход теперь самими Microsoft одобрен =)
Ну, никто не запрещает так делать (сами Microsoft по сути раньше так и делали), так что вопрос тут скорее о мнениях. (Если, конечно, не нужна гибкость, которую дает ручная регистрация: навешивать метадату на группы эндпоинтов, разбивать эндпоинты по проектам, подключать только часть из них, и т.п. - но это штуки ситуативные и не то чтобы совсем с автоматической регистрацией не совместимы.)
С моей точки зрения, в контроллерах это - задокументированная фича фреймворка, о которой разработчик узнает на этапе "пишем hello world", поэтому там такой подход логичен. В эндпоинтах же - это перемещается на уровень соглашений в проекте.
Уже проблема: к сожалению, нормально задокументированный проект - это скорее редкость, чем норма. И, даже если хорошая документация есть, это дополнительное время на прочтение, усваивание инфы.
И если у нас в проекте одно такое исключение, для эндпоинтов - ничего страшного, правда. Но, идут годы, проект растет, таких исключений уже куча. Вы так не планировали? Ну так другой разработчик подумал, раз есть одно, то почему бы и не два. А вы были в отпуске, или PR прошел мимо вас. А теперь это задача на рефакторинг, на которую менеджер не дает времени, потому что "что нам это даст?", и т.п.
И вот уже незаметненько, новые разработчики сидят и по несколько месяцев онбордятся, пытаясь разобраться что тут происходит. Еще и без возможности пройтись по всей цепочке Usages и отследить, потому что цепочки разорваны рефлексией.
А ведь есть неплохое правило "хороший код должен сам себя документировать". Конечно, его не везде получится соблюсти, но зачем просто так его нарушать.
Избавление от рефлексии целиком и переход на NativeAOT в большом проекте - это тема для отдельной статьи, и переход на Minimal API тут был бы лишь один из шагов. У меня тут меньше опыта, поэтому сразу и то и то я делать не пытался.
Да и, многим сейчас NuGet-зависимости не позволят, которые еще не стать совместимыми.
Но, пара моментов:
Json source generators опционально есть, вот пример для Minimal API. В идеале конечно, да, надо бы их использовать. MethodInfo я там, если посмотрите, парой абзацев ниже как раз показал на что заменить.
EF тоже может работать c Native AOT. Правда, с заметными ограничениями, и в целом, выстрелить себе в колено стало еще проще. Зато с такими ограничениями разница в производительности "в среднем" между EF и raw sql, которая и так стремительно уменьшается последние годы, еще меньше. В общем, вкусовщина
"Поиске" - я имею ввиду как у контроллеров, автоматического. Для регистрации эндпоинтов из моей статьи это выглядело бы приблизительно так:
Заглянул под капот контроллеров, там примерно тот же принцип в чуть более красивой обертке.
И, ничто не мешает так сделать для эндпоинтов. И разные сервисы для DI подхватывать например, или что еще вам нужно. Красиво - просто написал условный Handler для MediatR, а он автоматом уже зарегистрирован, никаких "опять забыл в DI прокинуть".
Вот только, злоупотребление такой черной магией несет за собой негативные последствия: меньшую гибкость, усложнение восприятия для новых разработчиков (в т.ч. разрыв цепочки usage, не проследишь что откуда вызывается). И старых, когда все нюансы работы проекта начнут забываться, и рефлексию, от которой стараемся избавиться
Стоит ли того 1 сэкономленная строчка кода на эндпоинт/сервис? Microsoft вот раньше, с контроллерами, считали, что можно сделать исключение. Сейчас, не безосновательно, они так не делают
По моему опыту - да, лучше, и по пониманию контекста, и по предлагаемым изменениям.
По слою UI на картинке проведен слайс, да. Но это не значит, что за один слайс будет отвечать сверху до низу один человек. Кто-то может писать БД часть, кто-то UI. На практике фронт часто отделен от бэка совсем, и там может быть вообще своя архитектура и бэкендеру об этом думать не нужно - все варьируется от проекта к проекту.
Но на бэке, вряд ли у вас будет что-то типа "я пишу DTO для этого эндпоинта, ты - преобразование моделей БД в DTO, а вот он - валидацию", условно говоря. Этим, как правило занимается один человек, в рамках одной задачи. Отсюда и логика архитектуры.
Но вот в целом, (прошу прощения если ошибаюсь), вы уже пытаетесь рассуждать нетривиальными абстракциями, имея довольно небольшие представления о том, как это все работает на практике. И проблема тут не в вас: я тонкой нитью по статье провожу, что, по моему мнению, мы слишком усложняем проекты и строим лишние абстракции там, где это не нужно. Что приводит к тому, что нам повально нужны сеньоры, которые смогут во всем этом добре разобраться. А VSA - пример того, как упростить это дело.
Я как-то видел проект, где ребята пытались строить CQRS, DDD и чистую архитектуру, пока в самом проекте было полно веселья типа эндпоинтов, возвращающих статус 200 с ошибкой внутри.
Да, VSA в текущем виде - не универсальное решение, хотя у меня есть подозрение что универсального решения и не будет: слишком уж размыты могут быть границы фичи от проекта к проекту. Да и сегодня твой эндпоинт рекомендаций для юзера учитывает только его купленные товары, а завтра пол базы корми нейронке, чтобы угадывать что захочет купить юзер.
В общем, правила может и можно сформулировать, только увы, головой все равно думать придется.
Но с LLM-ками да. По моему опыту, они могут подсказывать куда чаще и качественнее с VSA структурой (да и просто если писать код не забывая о KISS), чем с огородом из слоев и абстракций, даже при одинаковом функционале проекта.
=)
Все мы иногда тупни. Найти себе сплошных senior-ninja-10+yoe-developer в команду, чтобы поддерживать сложную архитектуру, и не испортить все в первый кранч/отпуск тимлида (и это еще если тимлид сам понимает, что делает) - это, конечно, здорово, но сложно и дорого.
Можно найти довольно много книг/статей, и вот прям шаг за шагом построить себе красивую архитектуру следуя всем заветам, и для этого не потребуется быть каким-то одаренным разработчиком. Однако, точно ли оно стоило потраченного времени? Точно ли бизнес выиграет от этого оверхэда? Точно ли коллега прочел ту же книгу и на одной волне с тобой, или просто делает вид?
На разных проектах свои правильные ответы на эти вопросы, но у меня есть ощущение, что к сожалению их обычно не задают себе.
Я там местами описал, в параграфах про DDD и границы подхода: далеко не весь код проекта получится (и стоит) поделить прям по слайсам: горизонтальные слои все равно останутся, и для меня суть VSA скорее в том, чтобы избавиться от горизонтальных слоев (и не размазывать код по всему проекту) там, где это возможно.
Так что, возможно, корректнее это было бы назвать VSA+HSA. Но если ваше понимание этого отличается, то интересно было бы услышать.
Не ну а что, оставят игры мейл ру, и все будут довольны. Кроме пользователей, но кому до них какое дело тут?
Другое дело, правда, что ее предоставление лишь ненадолго отсрочит неизбежное: сегодня информацию о компании, а завтра ключи шифрования.
Жаль, конечно, столь удобный мессенджер для работы терять, думаю возиться с обходом блокировок далеко не все захотят, но лучше уж так чем прогибаться, тут согласен.
Плюс последние годы AMD не могли нормально конкурировать с Intel в средне-высоком ценовом сегменте после того, как у последних получились очень удачные i3/5/7. И в то время как упустил годик на рынке GPU — потерял приличную аудиторию, то на рынке CPU Intel могла себе позволить несколько лет выпускать минорные апдейты: AMD все равно отстает плюс у старых процессоров все хорошо с производительностью.
— Почему он назван новым Gear VR? Это как назвать HTC Vive новой версией Oculus Rift. Этот шлем скорее ответ на Google Daydream.
— Сравнения с другими VR шлемами нет.
— Где нормальный обзор доступных приложений, а не просто ссылка на форум?
— О пульте управления написано одно предложение: он есть.
— О линзах тоже почти ничего. А их качество важно.
Я, конечно, все понимаю реклама товара который у вас есть, но с такими статьями хабр в сполшую рекламу в статьях скатится