Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Это ASP.NET разметка, а не Swashbuckle. И это пример, который максимум функционала показывает.
НС>·>Какая разница?
НС>Большая. Если ты прикрутишь еще и рукопашный OpenAPI, разметка asp.net никуда не денется.
Разметка может сгенерироваться. Например, если генерировать java по openapi для spring boot, оно нагенерит соответсвующие аннотации. С т.з. программиста нужно лишь знать, как в яп классы имплементируют интерфейсы, никакой разметки.
Если шарп это не умеет, то сабж.

НС>·>Это твоя цитата: "мы ORM кормим POCO, а потом эти же POCO выставляем в публичный API" — неясно к чему это всё было.
НС>К твоим вопросам про то где там генерация нескольких моделей поодному описанию.
Ты сам придумал генерацию нескольких моделей по одному описанию. У меня такого не было, вот я и спрашивал откуда ты это взял.

НС>·>Это называется straw man fallacy — насочинял за меня всякой дичи и потом успешно опроверг.
НС>Нет, это называется замыливание исходной темы. Ты уже куда только не пытался с нее сползти.
Исходная тема — дтошка с 40 полями, а не генерация нескольких моделей из одного описания.

vsb>·>Обычно получается так, что API описывается каким-то внешним способом (FIX, swagger, avro, protobuf, етс) и код таких классов генерируется.
vsb>Такой подход не пробовал, я пишу руками всё, автосгенерированные классы мне не нравятся (если только я сам не писал этот автогенератор).
Суть в том, что api обычно уже имеет некое описание независимое от каких-либо ЯП. Поэтому генерить из этих описаний java-код вполне разумно. Пишешь генератор ты сам или используешь готовый — неважно.

Где у FIX, ...etc несколько моделей?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Это ASP.NET разметка, а не Swashbuckle. И это пример, который максимум функционала показывает.
НС>·>Какая разница?
НС>Большая. Если ты прикрутишь еще и рукопашный OpenAPI, разметка asp.net никуда не денется.
Разметка может сгенерироваться. Например, если генерировать java по openapi для spring boot, оно нагенерит соответсвующие аннотации. С т.з. программиста нужно лишь знать, как в яп классы имплементируют интерфейсы, никакой разметки.
Вот эта вся колбаса сгенерирована:

@javax.annotation.Generated(...)
@Controller
@RequestMapping("${openapi.reflectoring.base-path:/v2}")
public class UserApiController implements UserApi {

https://reflectoring.io/spring-boot-openapi/

Если шарп это не умеет, то сабж.

НС>·>Это твоя цитата: "мы ORM кормим POCO, а потом эти же POCO выставляем в публичный API" — неясно к чему это всё было.
НС>К твоим вопросам про то где там генерация нескольких моделей поодному описанию.
Ты сам придумал генерацию нескольких моделей по одному описанию. У меня такого не было, вот я и спрашивал откуда ты это взял.

НС>·>Это называется straw man fallacy — насочинял за меня всякой дичи и потом успешно опроверг.
НС>Нет, это называется замыливание исходной темы. Ты уже куда только не пытался с нее сползти.
Исходная тема — дтошка с 40 полями, а не генерация нескольких моделей из одного описания.

vsb>·>Обычно получается так, что API описывается каким-то внешним способом (FIX, swagger, avro, protobuf, етс) и код таких классов генерируется.
vsb>Такой подход не пробовал, я пишу руками всё, автосгенерированные классы мне не нравятся (если только я сам не писал этот автогенератор).
Суть в том, что api обычно уже имеет некое описание независимое от каких-либо ЯП. Поэтому генерить из этих описаний java-код вполне разумно. Пишешь генератор ты сам или используешь готовый — неважно.

Где у FIX, ...etc несколько моделей?