Здравствуйте, ·, Вы писали:

НС>>Зато есть основной рабочий язык разработчика.
·>Ты говоришь о каком-то игрушечном проекте, видимо. В реальности одним ЯП ну никак не обойтись.

Где я написал, что обойтись? Но чем меньше языков, тем лучше.

НС>>Нет. Потому что в 99% случаев аннотации вообще не нужны, а там где нужны — они крайне примитивны и в стандартном синтаксисе основного языка.
·>Т.е. ты хочешь сказать, что можно наколбасить произвольный c# код и любому коду некий генератор может сгенерить юзабельную схему?

Что значит произвольный? Схема генерится по вполне определенным классам контроллеров. И да, вполне можно обойтись без специальной разметки для OpenAPI. Можно и вообще без разметки.

·>Имя генератора в студию!

Swashbuckle.

НС>>>>·>, имея все преимущества стротипизированного кода, а не писать всё с нуля.
НС>>>>Что нужно писать с нуля и почему?
НС>>·>Вот по твоему же заявлению: "писать клиентов нужно руками".
НС>>И где здесь "с нуля"?
·>А с чего?

Со всего что позволяет язык.

НС>>·>Ты говоришь, что модели разные. Генерация из одного описания даёт одну модель. Откуда разные?
НС>>В том и проблема, что модель получается одна, хотя нужны разные.
·>Разные модели чего? где? и для чего?

Ответ на это я уже много раз давал. По кругу ходить не собираюсь.

НС>>·>Не очень понял. Что значит "генерировать для описания метаданных"? Пример, плз. Накой вообще при генерации нужно какое-то описание каких-то метаданных?
НС>>Метаданные .NET ->
·>Подробнее, что такое "Метаданные .NET"? Аннотации?

In general, a static assembly can consist of four elements:

The assembly manifest, which contains assembly metadata.
Type metadata.
Microsoft intermediate language (MSIL) code that implements the types. It is generated by the compiler from one or more source code files.
A set of resources.

https://learn.microsoft.com/en-us/dotnet/standard/assembly/contents

НС>> генератор -> OpenAPI spec
·>Ок, ну допустим. А дальше?

Что дальше?

·>"писать клиентов нужно руками"?

Да, контракт клиента лучше описать руками. Но это не означает что нужно каждый раз все писать с нуля, генераторы это далеко не единственный способ реюза кода.

НС>>Потому что спецификация API это намного больше чем просто сериализация.
·>Понятно, конечно. Но тут мы вроде обсуждение с dto-шек с 40 полями начали. И именно это покрывается сериализацией

Нет конечно. Дтошки это прежде всего контракт, сериализация вторична. По одной и той же модели, к примеру, искаропки есть json и xml. В gRPC, разумеется, в силу его особенностей, приходится использовать protoc, но это именно его личная особенность.
А вот извив ума, по которому свойства в DTO оказывается нужны исключительно для сериализации — это тоже очень смелый подход к логике.