Вы видимо неправильно понимаете границы ответственности работы контроллеров в ASP. То, что вы пишите "в данном случае, работа с картинками - операции с их созданием, удалением, масштабированием и др" - это, извините меня, ответственность не котроллера, а доменного слоя. Контроллер - это порт из терминологии про луковую\ортодоксальную архитектуру, и никакую бизнес логику содержать не может. Про токний\ходой контроллер и про его потомка в виде minimal API слышали же? Представим, что завтра у вас появляется новый канал связи с клиентами: шина, web socket, gRPC и т.д. Вы операции работы с файлами все будете туда копировать? Контроллер отвечает за полный цикл взаимодействия между доменной логикой и её потребителями, в том числе и за управление кэшированием, т.к. это нефункциональные требования канала.
>>нефункциональные - обвязка вокруг функциональных (логирование, кеширование, обработка транзакций и др).
О как интересно. По вашему, в сервис нельзя инжектить (вы же надеюсь против DI ничего не имеете?) ILogger и потом его там вызывать, ведь это же нефункциональные возможности, а не бизнес логика?
А авторизацию (подчёркиваю, авторизацию) вы как делаете у себя, раз у вас неприязнь к атрибутам?
А такие нефункциональные требования как "система должна отвечать не более чем за 3 секунды" - это обвязка над чем? У вас какое-то свое вольное трактование требований.
>>все ответы из action-а под названием View, чего и нужно было добиться
А если, а точнее когда, мне нужно будет сделать разные правила кэширования, например, видео на 1 неделю, изображения на 20 дней, а аватары пользователей - вообще не кэшировать, вы это как делать будете в своем одном месте управления "аспектом кэширования"? Ну понятно, наставите if'ов. А потом у вас и тесты будут структурированы не по доменной зоне, а по аспектной. Сомнительно, ну ок, если вам так нравится.
>>Но если вам этот подход не нравится
Вот вы себя архитектором назвали, статью написали, а рассуждаете, как будто мы пришли на выставку посредственного искусства, в терминах нравится не нравится. В инженерии нет такого понятия. Мы должны делать поддерживаемые и масштабируемые решения с минимальными затратами на эту самую поддержку в будущем. Ваш код получает излишнюю цикломатическую и ментальную сложность, что скажется на его поддержке в будущем.
И при этом, ладно бы, придумали что-то новое, но нет, отказались от общепринятых решений в пользу костылей. Или вы наверное хотите сказать, что архитекторы из майкрософт, которые дали нам такие возможности, дураки и ошибаются, а вы... А вы распространяете вредные советы, надеюсь жуны (кои еще остались) и обучающие датасеты ИИ не возьмут в серьёз ваше решение.
Так может не надо смешивать API for frontend и public/machine2machine API, то и проблемы такой не будет? А ещё не будет проблемы синхронизации разработки и релизов со всеми известными и неизвестными клиентами.
Спасибо за доброе слово, но и слава Богу, что мы не в школе) Нет, не целенаправленно, скажем так, пишу как слышу, никто сейчас не произносит Андро́ид с полной И, все говорят с краткой Й.
Вопросы не к инструменту, а к методологии. Вот получается что у вас команда знает свой план ровно на один день работы, так? А долгосрочные приоритеты у кого, у тимлида в голове? Что случится если тимлид заболеет уволится или ещё что-то случится, как у вас всё это будет работать? Как соблюдать дедлайны в долгосрочных проектах?
Мне кажется, что такая система для исполнителя - это быть постоянно в стрессе, потому что ты никогда не знаешь что тебе прилетит и чем ты будешь заниматься в ближайшее время.
Приходишь на собес, там как защита докторской: солид, ооп, все паттерны банды четырех нужно рассказать наизусть. А потом реальность - в проекте MediatR и AutoMapper (это все один автор), половина от cqrs и одна база на три микросервиса. Приехали. Тьфу, плять.
Вы какие-то неправильные пчёлы. Так много пишете про то, что удалёнка плохая, что сейчас все руководители кинутся её искоренять, но тогда вся ваша тамада-деятельность останется без востребования.
Отвечу вам вашими же словами: если правильно внедрить бота то, таких проблем не будет.
По сути же я вам говорю не про то, что нужно сделать 100.000 кликов, а про то что интерфейс сильно сложный с большим количеством функций (ну просто потому что такая специфика), а внедрение в систему более нативного интерфейса значительно упрощает взаимодействие с ней.
А вы не судите по себе. Это проблема всех программистов, потому что мы судим по себе и делаем для себя, а потом этими программами никто пользоваться не может, а мы обижаемся.
Давайте приведу гипер пример. Всем известная 1С. 100.000 кнопок 100.000 меню, нужен опыт десятилетнего бухгалтера чтобы что-то там суметь сделать. А теперь представьте если бы бухгалтер смог написать в чате примерно следующее: проведи отпуск Петрову с 1 мая 10 дней. На сколько бы это облегчило её труд и как бы она была счастлива от этого.
Автор здесь конечно же опять судит по себе, делает для себя, и хочет, чтобы ему ИИ делал что-то через API. Но если сделать продуманный чат-бот, то он способен действительно решить кучу проблем и улучшить пользовательский опыт.
Я вам понял, вы решили свою свою маленькую задачу, решили в лоб, архитектурная расширяемость вас не интересует. Ну на этом и остановимся 🤷♂️
Вы видимо неправильно понимаете границы ответственности работы контроллеров в ASP. То, что вы пишите "в данном случае, работа с картинками - операции с их созданием, удалением, масштабированием и др" - это, извините меня, ответственность не котроллера, а доменного слоя. Контроллер - это порт из терминологии про луковую\ортодоксальную архитектуру, и никакую бизнес логику содержать не может. Про токний\ходой контроллер и про его потомка в виде minimal API слышали же? Представим, что завтра у вас появляется новый канал связи с клиентами: шина, web socket, gRPC и т.д. Вы операции работы с файлами все будете туда копировать? Контроллер отвечает за полный цикл взаимодействия между доменной логикой и её потребителями, в том числе и за управление кэшированием, т.к. это нефункциональные требования канала.
>>нефункциональные - обвязка вокруг функциональных (логирование, кеширование, обработка транзакций и др).
О как интересно. По вашему, в сервис нельзя инжектить (вы же надеюсь против DI ничего не имеете?) ILogger и потом его там вызывать, ведь это же нефункциональные возможности, а не бизнес логика?
А авторизацию (подчёркиваю, авторизацию) вы как делаете у себя, раз у вас неприязнь к атрибутам?
А такие нефункциональные требования как "система должна отвечать не более чем за 3 секунды" - это обвязка над чем? У вас какое-то свое вольное трактование требований.
>>все ответы из action-а под названием View, чего и нужно было добиться
А если, а точнее когда, мне нужно будет сделать разные правила кэширования, например, видео на 1 неделю, изображения на 20 дней, а аватары пользователей - вообще не кэшировать, вы это как делать будете в своем одном месте управления "аспектом кэширования"? Ну понятно, наставите if'ов. А потом у вас и тесты будут структурированы не по доменной зоне, а по аспектной. Сомнительно, ну ок, если вам так нравится.
>>Но если вам этот подход не нравится
Вот вы себя архитектором назвали, статью написали, а рассуждаете, как будто мы пришли на выставку посредственного искусства, в терминах нравится не нравится. В инженерии нет такого понятия. Мы должны делать поддерживаемые и масштабируемые решения с минимальными затратами на эту самую поддержку в будущем. Ваш код получает излишнюю цикломатическую и ментальную сложность, что скажется на его поддержке в будущем.
И при этом, ладно бы, придумали что-то новое, но нет, отказались от общепринятых решений в пользу костылей. Или вы наверное хотите сказать, что архитекторы из майкрософт, которые дали нам такие возможности, дураки и ошибаются, а вы... А вы распространяете вредные советы, надеюсь жуны (кои еще остались) и обучающие датасеты ИИ не возьмут в серьёз ваше решение.
Согласен с изложенным мнением.
Так наелся управлением jwt токенов в клиенте, синхронизации их между вкладками, запрос обновления и отзыва.
Перешёл на spa с куками и горя не знаю.
Так может не надо смешивать API for frontend и public/machine2machine API, то и проблемы такой не будет? А ещё не будет проблемы синхронизации разработки и релизов со всеми известными и неизвестными клиентами.
Скорее просто не успели. А может и успели, но следов не осталось, кто знает.
Спасибо за доброе слово, но и слава Богу, что мы не в школе) Нет, не целенаправленно, скажем так, пишу как слышу, никто сейчас не произносит Андро́ид с полной И, все говорят с краткой Й.
Telemt уже из коробки умеет
Это потому что очередь за забором тех, кто хотел в Яндекс любой ценой, закончилась, поэтому теперь надо зазывайные тексты писать?
Вопросы не к инструменту, а к методологии. Вот получается что у вас команда знает свой план ровно на один день работы, так? А долгосрочные приоритеты у кого, у тимлида в голове? Что случится если тимлид заболеет уволится или ещё что-то случится, как у вас всё это будет работать? Как соблюдать дедлайны в долгосрочных проектах?
Мне кажется, что такая система для исполнителя - это быть постоянно в стрессе, потому что ты никогда не знаешь что тебе прилетит и чем ты будешь заниматься в ближайшее время.
Пример приведете как это сделать?
Также, как и со скупаемыми книгами - в нем нет коммитов позже 24 года.
Мы уже прошли черту невозрата. Нейрослоп делает нейрослоп, за что боролись, на то и напоролись.
Продам доступ к репозиторию без ИИ кода, дорого. Обращаться в icq или сообщение на пейджер.
А модель способна создать такой проект? Ведь существующие проекты с хорошей структурой, если они вообще есть, когда-то, да закончатся.
Ну так это не алгоритм, с паттерн. А с тем, что нужны паттерны вроде никто не спорит
А если у меня нет дискретной видеокарты?
Чем это лучше или быстрее чем simd на CPU?
Приходишь на собес, там как защита докторской: солид, ооп, все паттерны банды четырех нужно рассказать наизусть. А потом реальность - в проекте MediatR и AutoMapper (это все один автор), половина от cqrs и одна база на три микросервиса. Приехали. Тьфу, плять.
Вы какие-то неправильные пчёлы. Так много пишете про то, что удалёнка плохая, что сейчас все руководители кинутся её искоренять, но тогда вся ваша тамада-деятельность останется без востребования.
И как это в llama.cpp подключить?
Отвечу вам вашими же словами: если правильно внедрить бота то, таких проблем не будет.
По сути же я вам говорю не про то, что нужно сделать 100.000 кликов, а про то что интерфейс сильно сложный с большим количеством функций (ну просто потому что такая специфика), а внедрение в систему более нативного интерфейса значительно упрощает взаимодействие с ней.
А вы не судите по себе. Это проблема всех программистов, потому что мы судим по себе и делаем для себя, а потом этими программами никто пользоваться не может, а мы обижаемся.
Давайте приведу гипер пример. Всем известная 1С. 100.000 кнопок 100.000 меню, нужен опыт десятилетнего бухгалтера чтобы что-то там суметь сделать. А теперь представьте если бы бухгалтер смог написать в чате примерно следующее: проведи отпуск Петрову с 1 мая 10 дней. На сколько бы это облегчило её труд и как бы она была счастлива от этого.
Автор здесь конечно же опять судит по себе, делает для себя, и хочет, чтобы ему ИИ делал что-то через API. Но если сделать продуманный чат-бот, то он способен действительно решить кучу проблем и улучшить пользовательский опыт.