Обзор отличный, мой коммент не критика, а уточнение. Я бы сделал больше акцент на OpenApi от Microsoft, на который стоит переходить, а UI вообще можно и оба сразу добавить :)
Но в какой-то момент основные разработчики Swashbuckle покинули проект и начались трудности: копился техдолг, и запоздалая поддержка .NET 8 привела к проблемам совместимости.
Действительно, такой период был. Но сейчас проект активно развивается, все новые фичи платформы поддерживаются, релизы выпускаются. Нет причин для беспокойства.
Scalar безусловно проект интересный, но стоит обратить внимание, что это коммерческая разработка, где Scalar .NET — не отдельный самостоятельный репозиторий, а интеграционный пакет. В связи с этим есть определённые риски, которые надо учитывать.
Спасибо за содержательный ответ — в нём действительно есть о чём задуматься.
Что касается "синтетичности" — да, вы правы, суть действительно может быть обличена в любую форму. Но вот в чём дело: когда люди обмениваются мнениями, особенно в живом диалоге, им важно не только то, что сказано, но и кем, зачем, в каком контексте, с какой эмоцией, позицией, опытом.
ИИ, даже вдохновлённый удачным промптом, может дать красивый текст, но он не выражает позицию человека напрямую — он её транслирует с фильтрацией, интерпретацией, порой безотносительно личной ответственности. И если вместо ответа человека приходит абстрактный текст, это оставляет чувство отсутствия собеседника. Как будто разговариваешь не с личностью, а с облаком.
Поэтому в обсуждениях, особенно когда важен обмен взглядами, хочется видеть именно человека, даже если он формулирует неидеально, с ошибками или просто неуклюже. Это всё равно живое, и потому — ценное.
Что касается сути и промптов — согласен, за каждым промптом стоит некая воля. Но она работает иначе, чем прямая речь. Промпт — это акт конструирования, не высказывания. А значит, даже при вложенном замысле, результат всё же больше похож на имитацию смысла, чем на его подлинное проявление.
По поводу выделения бизнес-логики в СУБД — вопрос, безусловно, технически интересный. Поддерживаю мысль, что это непопулярно у многих архитекторов сегодня, поскольку нарушает принципы разделения ответственности и усложняет масштабирование. Но всё зависит от контекста: если логика плотно завязана на данные и важна производительность — иногда это оправдано. Можем обсудить подробнее, если интересно.
И спасибо вам — за тон, за внимание к деталям и готовность воспринимать чужую точку зрения. Это редкость.
Похоже не за горами, когда в комментариях введут кнопку: "Мне важно именно твоё мнение, а не тупая справка от ИИ."
А выглядит это крайне некрасиво и оставляет только негативные впечатления о человеке, который отвечает на вопрос с помощью ИИ. Такой человек видимо считает окружающих идиотами, неспособными самостоятельно пользоваться чат-ботами LLM.
Взять тот же AST. Например, у меня было раньше сложение и вычитание. Я добавляю умножение и деление. Либо каждая реализация должна поддержать их, либо всё сломается. Это не тот случай, когда мы "расширяем" и никого это не затрагивает. Расширение элементов автоматически, 100% должно гарантировано приводить к необходимости поддержки новых элементов, никаких компромиссов. Да, при добавлении типов, везде должны быть привнесены проверки, повсюду. Именно так, и никак иначе.
Это моё ИМХО :) Введение значимых типов в язык это очень хорошо для производительности, но из стройной иерархии "всё есть объект" очень выбивается. В последних версиях дотнета большой упор на поддержку структур, стековые ссылки, readonly-структуры. Но выглядит всё как костыль, хоть и добротный. Взять например отсутствие возможности закрыть дефолтный конструктор и определить свой иницилизатор, подковёрные игры с duck typing (в using), всё это хорошо, но очень непрозрачно.
Оно будет работать. Я говорю про то, что нет никакой надобности делать класс "Договор" с методом "Подписать" и другими методами, которые пытаются имитировать действия над договором в реальном мире. Есть требуемое состояние, к которому надо привести, есть текущее состояние, набор правил, и инфраструктура, которая организует и оркестрирует, оперируя уже программными концепциями: команда, запрос, сессия, транзакция, сага. ООП нужен для программных концепций, абстракций, а не для реального мира.
За 20 лет стажа ни разу не встречал никакого пафоса, ритуалов или ещё каких приседаний, молебен и наставлений с придыханием. Вы где это всё берёте? Всю жизнь в практике ООП это что-то существующее естественно, как и всё остальное, один из инструментов разработки. Или речь идёт о каких-то вбросах в интернетах?
Это всё понятно, тут наверное и вопросов нет нужно ли ООП, зачем ООП, кому всё это нужно, кому нужны эти наследования и инкапсуляции, давайте писать просто функции и структуры :)
Статический полиформизм это синтаксический сахар. Да, без боксинга можно обойтись в передаче параметров, но оно чаще всего ляжет либо в поле класса, либо как элемент коллекции, так что и без боксинга структуры оказываются в куче )
42.ToString() выполняется на стеке только благодаря костылю .NET, в виде ValueObject, который с одной стороны наследуется от Object, с другой стороны не является ссылочным типом, пока его не присвоили в object (boxing). И это простой пример, потому как обычно, в стек много не положишь, а объектов нужно всяких много. Где же им ещё размещаться, как не в куче?
А что мне делать, если мне нужен результат этой отправки? Или хотя бы я должен убедиться, что событие получено и обработано, потому что если я продолжу логику, то будет рассинхрон. Например, отправляю событие создать пользователя, а следом, пользователь кладёт в корзину... а пользователя-то ещё может не оказаться к тому моменту.
Противоречие в том, что из класса часто пытаются смоделировать поведение "как в жизни". А это неправильно, от этого в конце концов уходят в анемичные модели и потом ругают ООП. Хотелось бы сказать, что ООП используют неправильно, но всё глубже. Это программирование используют неправильно, не понимая основных базовых концепций. Что в БД у нас не договор, и не клиент, не юзер, не склад, не товар, а записи об их существовании. И всего лишь проводим изменения в БД, или делаем запросы чаще всего, из подавляющего количество работы это учётные системы.
Представьте, что бумажный паспорт имеет функцию "получить деньги на кассе" или "заключить сделку". Абсурд? Но когда мы пишем класс, с подобными методами, уже не абсурд :)
Только если это безопасно и вычисляется на этапе компиляции. Он может не использовать виртуальный вызов для точно известного на момент вызова типа и его метода. Но в примере выше так не будет, так как я как разработчик привёл значение к ссылке на общий объект.
Если отправка события некоему объекту это синхронное действо, то разницы никакой нет, кроме того, каким словом это называть. А вот если отправка события летит в очередь, то это уже совсем-совсем другое дело.
В любом мало-мальском современном ЯП можно использовать такой подход, но удовольствия в этом мало, если применять вообще везде. Такое нужно применять когда в этом есть необходимость. Например, для распределённых вычислений, берём Akka или Orleans. Для стримов берём кафку, если синхронный реквест/реплай нужен, то городим огород на AMQP или берём Nats. Ну а если это монолит, то очереди в памяти, в гошке те же ченнелы.
Я хочу сказать, что мы ничего не лишились. Вы описываете один из тех случаев, когда подход строится по принципу "всё есть....": всё есть объект, все структуры и переменные неизменны, все взаимодействия это события, всё есть функция с каррированием. Конечно это даёт определённые преимущества, например, для параллелизма, но и в то же время награждает существенными болезненными ограничениями, где казалось бы простые вещи приходится городить костылями.
Мне по душе мульти-парадигменный подход, который даёт возможность выбирать наиболее подходящие паттерны под задачу.
"Извне" работает только если программист реализует компонент, который используется другими программистами, при реализации логики. А зачастую это компонент, который уже зацеплен к презентации, не будет это использовать другой программист, это конечная логика для пользователя. Т.е. это JSON для фронта, или отображаемая форма с контролами, или HTML.
Договор это зафиксированные юридически отношения с кастомером, в котором прописывается комплекс услуг, товаров, физических действий, осуществляемых в реальности, и только часть из них фиксируется в информационной системе.
И когда пытаются создать класс "Договор" или "Клиент", и описать в нём методы 1 в 1 соответствующие реальности, это не работает просто из-за нарушения понятий.
В информационной системе "Договор" это запись, отображающая какую-то часть бизнеса в реальном мере, а точнее какие-то аспекты этого состояния. И мы работаем с состоянием, а не с сами договором. Мы не можем "Подписать" договор в системе, мы можем изменить статус с "Не подписано" на "Подписано" в его состоянии. Поэтому метод "Подписать" в классе это искажение реальности. Новички об это часто спотыкаются, и некоторые с завидным упорством пытаются смоделировать реальный мир в классе. Получается это плохо, и, самое главное, инфраструктура, синтаксис языка, особенности используемого фреймворка смешиваются с терминологией бизнеса. И получается каша, которую сопровождать потом сложно.
Зачем засирать хабр ИИ-шным контентом? Просто делитесь промптами, так хоть будет честно. И люди будут учиться промпты писать.
Обзор отличный, мой коммент не критика, а уточнение. Я бы сделал больше акцент на OpenApi от Microsoft, на который стоит переходить, а UI вообще можно и оба сразу добавить :)
Действительно, такой период был. Но сейчас проект активно развивается, все новые фичи платформы поддерживаются, релизы выпускаются. Нет причин для беспокойства.
Scalar безусловно проект интересный, но стоит обратить внимание, что это коммерческая разработка, где Scalar .NET — не отдельный самостоятельный репозиторий, а интеграционный пакет. В связи с этим есть определённые риски, которые надо учитывать.
Всё пропало? Куда бежать? Где спасение от ИИ?
Спасибо за содержательный ответ — в нём действительно есть о чём задуматься.
Что касается "синтетичности" — да, вы правы, суть действительно может быть обличена в любую форму. Но вот в чём дело: когда люди обмениваются мнениями, особенно в живом диалоге, им важно не только то, что сказано, но и кем, зачем, в каком контексте, с какой эмоцией, позицией, опытом.
ИИ, даже вдохновлённый удачным промптом, может дать красивый текст, но он не выражает позицию человека напрямую — он её транслирует с фильтрацией, интерпретацией, порой безотносительно личной ответственности. И если вместо ответа человека приходит абстрактный текст, это оставляет чувство отсутствия собеседника. Как будто разговариваешь не с личностью, а с облаком.
Поэтому в обсуждениях, особенно когда важен обмен взглядами, хочется видеть именно человека, даже если он формулирует неидеально, с ошибками или просто неуклюже. Это всё равно живое, и потому — ценное.
Что касается сути и промптов — согласен, за каждым промптом стоит некая воля. Но она работает иначе, чем прямая речь. Промпт — это акт конструирования, не высказывания. А значит, даже при вложенном замысле, результат всё же больше похож на имитацию смысла, чем на его подлинное проявление.
По поводу выделения бизнес-логики в СУБД — вопрос, безусловно, технически интересный. Поддерживаю мысль, что это непопулярно у многих архитекторов сегодня, поскольку нарушает принципы разделения ответственности и усложняет масштабирование. Но всё зависит от контекста: если логика плотно завязана на данные и важна производительность — иногда это оправдано. Можем обсудить подробнее, если интересно.
И спасибо вам — за тон, за внимание к деталям и готовность воспринимать чужую точку зрения. Это редкость.
Похоже не за горами, когда в комментариях введут кнопку: "Мне важно именно твоё мнение, а не тупая справка от ИИ."
А выглядит это крайне некрасиво и оставляет только негативные впечатления о человеке, который отвечает на вопрос с помощью ИИ. Такой человек видимо считает окружающих идиотами, неспособными самостоятельно пользоваться чат-ботами LLM.
Взять тот же AST. Например, у меня было раньше сложение и вычитание. Я добавляю умножение и деление. Либо каждая реализация должна поддержать их, либо всё сломается. Это не тот случай, когда мы "расширяем" и никого это не затрагивает. Расширение элементов автоматически, 100% должно гарантировано приводить к необходимости поддержки новых элементов, никаких компромиссов. Да, при добавлении типов, везде должны быть привнесены проверки, повсюду. Именно так, и никак иначе.
А миграции? Ведь балк нужен раз в сто лет, а миграции нужны всегда.
Это моё ИМХО :) Введение значимых типов в язык это очень хорошо для производительности, но из стройной иерархии "всё есть объект" очень выбивается. В последних версиях дотнета большой упор на поддержку структур, стековые ссылки, readonly-структуры. Но выглядит всё как костыль, хоть и добротный. Взять например отсутствие возможности закрыть дефолтный конструктор и определить свой иницилизатор, подковёрные игры с duck typing (в using), всё это хорошо, но очень непрозрачно.
Оно будет работать. Я говорю про то, что нет никакой надобности делать класс "Договор" с методом "Подписать" и другими методами, которые пытаются имитировать действия над договором в реальном мире. Есть требуемое состояние, к которому надо привести, есть текущее состояние, набор правил, и инфраструктура, которая организует и оркестрирует, оперируя уже программными концепциями: команда, запрос, сессия, транзакция, сага. ООП нужен для программных концепций, абстракций, а не для реального мира.
За 20 лет стажа ни разу не встречал никакого пафоса, ритуалов или ещё каких приседаний, молебен и наставлений с придыханием. Вы где это всё берёте? Всю жизнь в практике ООП это что-то существующее естественно, как и всё остальное, один из инструментов разработки. Или речь идёт о каких-то вбросах в интернетах?
Это всё понятно, тут наверное и вопросов нет нужно ли ООП, зачем ООП, кому всё это нужно, кому нужны эти наследования и инкапсуляции, давайте писать просто функции и структуры :)
Статический полиформизм это синтаксический сахар. Да, без боксинга можно обойтись в передаче параметров, но оно чаще всего ляжет либо в поле класса, либо как элемент коллекции, так что и без боксинга структуры оказываются в куче )
42.ToString() выполняется на стеке только благодаря костылю .NET, в виде ValueObject, который с одной стороны наследуется от Object, с другой стороны не является ссылочным типом, пока его не присвоили в object (boxing). И это простой пример, потому как обычно, в стек много не положишь, а объектов нужно всяких много. Где же им ещё размещаться, как не в куче?
А что мне делать, если мне нужен результат этой отправки? Или хотя бы я должен убедиться, что событие получено и обработано, потому что если я продолжу логику, то будет рассинхрон. Например, отправляю событие создать пользователя, а следом, пользователь кладёт в корзину... а пользователя-то ещё может не оказаться к тому моменту.
Противоречие в том, что из класса часто пытаются смоделировать поведение "как в жизни". А это неправильно, от этого в конце концов уходят в анемичные модели и потом ругают ООП. Хотелось бы сказать, что ООП используют неправильно, но всё глубже. Это программирование используют неправильно, не понимая основных базовых концепций. Что в БД у нас не договор, и не клиент, не юзер, не склад, не товар, а записи об их существовании. И всего лишь проводим изменения в БД, или делаем запросы чаще всего, из подавляющего количество работы это учётные системы.
Представьте, что бумажный паспорт имеет функцию "получить деньги на кассе" или "заключить сделку". Абсурд? Но когда мы пишем класс, с подобными методами, уже не абсурд :)
Только если это безопасно и вычисляется на этапе компиляции. Он может не использовать виртуальный вызов для точно известного на момент вызова типа и его метода. Но в примере выше так не будет, так как я как разработчик привёл значение к ссылке на общий объект.
Если отправка события некоему объекту это синхронное действо, то разницы никакой нет, кроме того, каким словом это называть. А вот если отправка события летит в очередь, то это уже совсем-совсем другое дело.
В любом мало-мальском современном ЯП можно использовать такой подход, но удовольствия в этом мало, если применять вообще везде. Такое нужно применять когда в этом есть необходимость. Например, для распределённых вычислений, берём Akka или Orleans. Для стримов берём кафку, если синхронный реквест/реплай нужен, то городим огород на AMQP или берём Nats. Ну а если это монолит, то очереди в памяти, в гошке те же ченнелы.
Я хочу сказать, что мы ничего не лишились. Вы описываете один из тех случаев, когда подход строится по принципу "всё есть....": всё есть объект, все структуры и переменные неизменны, все взаимодействия это события, всё есть функция с каррированием. Конечно это даёт определённые преимущества, например, для параллелизма, но и в то же время награждает существенными болезненными ограничениями, где казалось бы простые вещи приходится городить костылями.
Мне по душе мульти-парадигменный подход, который даёт возможность выбирать наиболее подходящие паттерны под задачу.
"Извне" работает только если программист реализует компонент, который используется другими программистами, при реализации логики. А зачастую это компонент, который уже зацеплен к презентации, не будет это использовать другой программист, это конечная логика для пользователя. Т.е. это JSON для фронта, или отображаемая форма с контролами, или HTML.
Договор это зафиксированные юридически отношения с кастомером, в котором прописывается комплекс услуг, товаров, физических действий, осуществляемых в реальности, и только часть из них фиксируется в информационной системе.
И когда пытаются создать класс "Договор" или "Клиент", и описать в нём методы 1 в 1 соответствующие реальности, это не работает просто из-за нарушения понятий.
В информационной системе "Договор" это запись, отображающая какую-то часть бизнеса в реальном мере, а точнее какие-то аспекты этого состояния. И мы работаем с состоянием, а не с сами договором. Мы не можем "Подписать" договор в системе, мы можем изменить статус с "Не подписано" на "Подписано" в его состоянии. Поэтому метод "Подписать" в классе это искажение реальности. Новички об это часто спотыкаются, и некоторые с завидным упорством пытаются смоделировать реальный мир в классе. Получается это плохо, и, самое главное, инфраструктура, синтаксис языка, особенности используемого фреймворка смешиваются с терминологией бизнеса. И получается каша, которую сопровождать потом сложно.