Здравствуйте, ·, Вы писали:
НС>>Зато есть основной рабочий язык разработчика. ·>Ты говоришь о каком-то игрушечном проекте, видимо. В реальности одним ЯП ну никак не обойтись.
Где я написал, что обойтись? Но чем меньше языков, тем лучше.
НС>>Нет. Потому что в 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.
Да, контракт клиента лучше описать руками. Но это не означает что нужно каждый раз все писать с нуля, генераторы это далеко не единственный способ реюза кода.
НС>>Потому что спецификация API это намного больше чем просто сериализация. ·>Понятно, конечно. Но тут мы вроде обсуждение с dto-шек с 40 полями начали. И именно это покрывается сериализацией
Нет конечно. Дтошки это прежде всего контракт, сериализация вторична. По одной и той же модели, к примеру, искаропки есть json и xml. В gRPC, разумеется, в силу его особенностей, приходится использовать protoc, но это именно его личная особенность.
А вот извив ума, по которому свойства в DTO оказывается нужны исключительно для сериализации — это тоже очень смелый подход к логике.
Здравствуйте, Gt_, Вы писали:
НС>>Ты меня с кем то перепутал. Я наоборот предлагал наследование не использовать по возможности.
Gt_>я ничего не путаю, именно ты собрался в рукопашную писать модели, пользуясь выразительностью языка (тм)
И при чем тут наследование? Наследование в том же REST — редкостный геморой.
Gt_>по мне, так очень необычный подход.
Ну это по тебе. А так очень распространенный подход.
Gt_>вот в случае основной и исторической таблички
Мужик, я понятия не имею про твою специфику. И, если честно, желания вникать в нее нет. Делай как тебе удобнее.
Здравствуйте, Ночной Смотрящий, Вы писали: НС>Где я написал, что обойтись? Но чем меньше языков, тем лучше.
Ага. И только у тебя получается, что три меньше двух. НС>>>Нет. Потому что в 99% случаев аннотации вообще не нужны, а там где нужны — они крайне примитивны и в стандартном синтаксисе основного языка. НС>·>Т.е. ты хочешь сказать, что можно наколбасить произвольный c# код и любому коду некий генератор может сгенерить юзабельную схему? НС>Что значит произвольный? Схема генерится по вполне определенным классам контроллеров. И да, вполне можно обойтись без специальной разметки для OpenAPI. Можно и вообще без разметки.
Ок, уже теплее. Как эти классы контроллеров определяются? Как определяется что пойдёт в хедер, что в квери и т.п.? Ответ тут: НС>Swashbuckle.
Вот если это не EDSL, то я папа римский.
builder.Services.AddSwaggerGen(options =>
{
options.SwaggerDoc("v1", new OpenApiInfo
{
Version = "v1",
Title = "ToDo API",
Description = "An ASP.NET Core Web API for managing ToDo items",
TermsOfService = new Uri("https://example.com/terms"),
Contact = new OpenApiContact
{
Name = "Example Contact",
Url = new Uri("https://example.com/contact")
},
License = new OpenApiLicense
{
Name = "Example License",
Url = new Uri("https://example.com/license")
}
});
});
...
[HttpDelete("{id}")]
[ProducesResponseType(StatusCodes.Status201Created)]
[ProducesResponseType(StatusCodes.Status400BadRequest)]
[Required]
[DefaultValue(false)]
[ApiController]
[Route("api/[controller]")]
[Produces("application/json")]
Домашнее задание — выяснить, что означает L в аббревиатуре EDSL и научиться считать до трёх. НС>>>>>·>, имея все преимущества стротипизированного кода, а не писать всё с нуля. НС>>>>>Что нужно писать с нуля и почему? НС>>>·>Вот по твоему же заявлению: "писать клиентов нужно руками". НС>>>И где здесь "с нуля"? НС>·>А с чего? НС>Со всего что позволяет язык.
Словоблудие. НС>>>·>Ты говоришь, что модели разные. Генерация из одного описания даёт одну модель. Откуда разные? НС>>>В том и проблема, что модель получается одна, хотя нужны разные. НС>·>Разные модели чего? где? и для чего? НС>Ответ на это я уже много раз давал. По кругу ходить не собираюсь.
Ну значит я не понял твой ответ. Ты там критиковал использование тех же POCO в ORM и в REST. Конечно, так делать не надо, и я такое никогда не предлагал. Точнее я ответ твой понял, но он был не в тему.
"Модели разные, а мы их пытаемся генератором преобразовать автоматически, получаем проблемы о которых я писал." — кто "мы" пытается модели преобразовывать генератором? Каким генератором? Зачем вообще преобразовывать модели генератором?
Может ты плохо представляешь как это работает? Вот конкретный пример:
1. пишем openapi спеку
2. Запускаем генератор, получаем "рыбу" — набор interface с методами и классы для dto-шек. Эту рыбу можно запаковать как отдельную либу (в принципе необязательно, код можно генерировать и по месту использования).
всё это дело будет густо обвешано аннотациями и кусками кода для всяких дефолтных значений, валидаций, маппингов на урлы-хедеры-етс. То что ты пишешь ручками в виде [DefaultValue(false)] и [HttpDelete("{id}")].
3. На сервере подключаем эту либу и реализуем интерфейсы как классы контроллеров.
пишем как-то так
class UserController implements UserApi {
@Override UserDto getUserByName(String name) {return new UserDto(...);}
}
httpServer.handle(new UserController(...));
4. На клиенте подключаем эту же либу и используем эти же интерфейсы, чтобы дёргать сервер.
пишем как-то так
var rest = new RestClient("http://server.address...");
var userApi = rest.getUserApi();
var userDto = userApi.getUserByName("vasya");
5. всё.
Тебе нужно знать два языка — язык спеки openapi и язык программирования java. Никаких аннотаций писать не надо, изучать никаких библиотек не надо, максимум несколько опций генератора задать в настройках проекта.
Дальше по той же спеке можно генерить "рыбу" для javascript/typescript в браузере и т.п. А если захочется переписать кусочек сервера на scala/kotlin/etc — можно использовать соответствующий генератор для генерации более language-friendly рыбы.
Мода на code-first в java была лет 10-15 назад... Врочем и сейчас может использоваться в мелких проектах — запилить и забыть. А для дотнета наконец-то настал "2023й год на дворе, очнись"... НС>>>·>Не очень понял. Что значит "генерировать для описания метаданных"? Пример, плз. Накой вообще при генерации нужно какое-то описание каких-то метаданных? НС>>>Метаданные .NET -> НС>·>Подробнее, что такое "Метаданные .NET"? Аннотации? НС>https://learn.microsoft.com/en-us/dotnet/standard/assembly/contents
Вот эти метаданные и аннотации и должны описываться неким формальным языком, чтобы генератор мог работать и выдавать что-то вменяемое. НС>>> генератор -> OpenAPI spec НС>·>Ок, ну допустим. А дальше? НС>Что дальше?
Ну сгенерили мы OpenAPI spec. Как и любой сгенерённый код она практически не человекочитаема, тулзы переваривать нормально не умеют... И накой? Что дальше с ней делать? НС>·>"писать клиентов нужно руками"? НС>Да, контракт клиента лучше описать руками. Но это не означает что нужно каждый раз все писать с нуля, генераторы это далеко не единственный способ реюза кода.
Почему лучше? Какие способы реюза ты предлагаешь? НС>>>Потому что спецификация API это намного больше чем просто сериализация. НС>·>Понятно, конечно. Но тут мы вроде обсуждение с dto-шек с 40 полями начали. И именно это покрывается сериализацией НС>Нет конечно. Дтошки это прежде всего контракт, сериализация вторична.
Вторична да. Но в контексте дтошек в 40 полей это и есть — передать развесистый документ между системами — сериализовать по спеке, прогнать байтики, десериализовать. Что собственно сгенерированный из спек код и делает в основном. НС> По одной и той же модели, к примеру, искаропки есть json и xml. В gRPC, разумеется, в силу его особенностей, приходится использовать protoc, но это именно его личная особенность.
Такая же личная особенность есть в thrift, avro, sbe, fix, asn.1 и т.п. НС>А вот извив ума, по которому свойства в DTO оказывается нужны исключительно для сериализации — это тоже очень смелый подход к логике.
Согласен. Не извивайся так больше.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
НС>>Swashbuckle. ·>[cut=Вот если это не EDSL, то я папа римский.]
Это ASP.NET разметка, а не Swashbuckle. И это пример, который максимум функционала показывает.
·>Домашнее задание — выяснить, что означает L в аббревиатуре EDSL и научиться считать до трёх.
Перешел на личности — слил.
НС>>Ответ на это я уже много раз давал. По кругу ходить не собираюсь. ·>Ну значит я не понял твой ответ. Ты там критиковал использование тех же POCO в ORM
Аргументы, похоже кончились. Началось хамство и подтасовки. На сем стоит закончить.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Swashbuckle. НС>·>[cut=Вот если это не EDSL, то я папа римский.] НС>Это ASP.NET разметка, а не Swashbuckle. И это пример, который максимум функционала показывает.
Какая разница? asp.net это не c# язык, а большой фреймворк со своим edsl который тоже надо знать и учить.
НС>·>Домашнее задание — выяснить, что означает L в аббревиатуре EDSL и научиться считать до трёх. НС>Перешел на личности — слил.
whatever.
НС>>>Ответ на это я уже много раз давал. По кругу ходить не собираюсь. НС>·>Ну значит я не понял твой ответ. Ты там критиковал использование тех же POCO в ORM НС> НС>Аргументы, похоже кончились. Началось хамство и подтасовки. На сем стоит закончить.
Где ты тут увидел хамство и подтасовки?
Это твоя цитата: "мы ORM кормим POCO, а потом эти же POCO выставляем в публичный API" — неясно к чему это всё было. Я никогда не предлагал ничего подобного.
Это называется straw man fallacy — насочинял за меня всякой дичи и потом успешно опроверг.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
НС>>Это ASP.NET разметка, а не Swashbuckle. И это пример, который максимум функционала показывает. ·>Какая разница?
Большая. Если ты прикрутишь еще и рукопашный OpenAPI, разметка asp.net никуда не денется.
НС>>·>Домашнее задание — выяснить, что означает L в аббревиатуре EDSL и научиться считать до трёх. НС>>Перешел на личности — слил. ·>whatever.
НС>>·>Ну значит я не понял твой ответ. Ты там критиковал использование тех же POCO в ORM НС>> НС>>Аргументы, похоже кончились. Началось хамство и подтасовки. На сем стоит закончить. ·>Где ты тут увидел хамство
Там где ты перешел на личности.
·>Это твоя цитата: "мы ORM кормим POCO, а потом эти же POCO выставляем в публичный API" — неясно к чему это всё было.
К твоим вопросам про то где там генерация нескольких моделей поодному описанию.
·>Это называется straw man fallacy — насочинял за меня всякой дичи и потом успешно опроверг.
Нет, это называется замыливание исходной темы. Ты уже куда только не пытался с нее сползти.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Это 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 {
Если шарп это не умеет, то сабж.
НС>·>Это твоя цитата: "мы ORM кормим POCO, а потом эти же POCO выставляем в публичный API" — неясно к чему это всё было. НС>К твоим вопросам про то где там генерация нескольких моделей поодному описанию.
Ты сам придумал генерацию нескольких моделей по одному описанию. У меня такого не было, вот я и спрашивал откуда ты это взял.
НС>·>Это называется straw man fallacy — насочинял за меня всякой дичи и потом успешно опроверг. НС>Нет, это называется замыливание исходной темы. Ты уже куда только не пытался с нее сползти.
Исходная тема — дтошка с 40 полями, а не генерация нескольких моделей из одного описания.
vsb>·>Обычно получается так, что API описывается каким-то внешним способом (FIX, swagger, avro, protobuf, етс) и код таких классов генерируется.
vsb>Такой подход не пробовал, я пишу руками всё, автосгенерированные классы мне не нравятся (если только я сам не писал этот автогенератор).
Суть в том, что api обычно уже имеет некое описание независимое от каких-либо ЯП. Поэтому генерить из этих описаний java-код вполне разумно. Пишешь генератор ты сам или используешь готовый — неважно.
Где у FIX, ...etc несколько моделей?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
S>>>Вобще то много чего есть. Даже summary берет S>·>Как я вижу, оно не умеет серверный код генерить. Вот вы и мучаетесь. Сабж... S>Какой такой серверный код?
Ну например, создать заготовку rest-сервера по openapi спеке, в которую останется вписать код имплементации методов.
S>Есть Source Generator. Можно, что угодно нагенерить!
Новости из будущего? Вот когда нагенерите, тогда приходите, может сабж и случится.
Впрочем, вижу вот целых 2 месяца назад наконец-то появилась какая-то поделка https://github.com/s-tarasov/ST.NSwag.ServerSourceGenerator
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
S>>Есть Source Generator. Можно, что угодно нагенерить! ·>Новости из будущего? Вот когда нагенерите, тогда приходите, может сабж и случится. ·>Впрочем, вижу вот целых 2 месяца назад наконец-то появилась какая-то поделка https://github.com/s-tarasov/ST.NSwag.ServerSourceGenerator
По уму там и Source Generator не нужен. Он нужен только для модель изменяемая.
А так я не вижу проблем. Можно и самому по модели методы написать и DTO сгенерить. Не вижу каких то проблем.
Только странно как то из описания генерить сервер. Больше нужен клиент.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>>Есть Source Generator. Можно, что угодно нагенерить! S>·>Новости из будущего? Вот когда нагенерите, тогда приходите, может сабж и случится. S>·>Впрочем, вижу вот целых 2 месяца назад наконец-то появилась какая-то поделка https://github.com/s-tarasov/ST.NSwag.ServerSourceGenerator S> По уму там и Source Generator не нужен. Он нужен только для модель изменяемая.
Ну rest спеки меняются иногда, да.
S> А так я не вижу проблем. Можно и самому по модели методы написать
Как именно написать? Вручную? Как потом валидировать, что написанное соответствует спеке?
S> и DTO сгенерить. Не вижу каких то проблем.
Как сгенерить-то?
S> Только странно как то из описания генерить сервер. Больше нужен клиент.
И то, и то нужно. В этом и сила, что клиент и сервер генерятся на основе одной и той же спеки, что гарантирует их совместимость. Притом разные части api можно реализовывать на разном стеке технологий в зависимости от требований.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
S>> и DTO сгенерить. Не вижу каких то проблем. ·>Как сгенерить-то?
Да легко! SG пишут не боги. S>> Только странно как то из описания генерить сервер. Больше нужен клиент. ·>И то, и то нужно. В этом и сила, что клиент и сервер генерятся на основе одной и той же спеки, что гарантирует их совместимость. Притом разные части api можно реализовывать на разном стеке технологий в зависимости от требований.
Да не вижу особых проблем написать. Или это какой то охрененный хак что бы по json описанию сложность какая то сгенерить partial класс с partial нужными методами и параметрами.
Ну и сгенерить класс с методами внутри NotImplementedException , если такого файла нет и добавить его в проект.
Это вообще студенческая поделка!
и солнце б утром не вставало, когда бы не было меня
Gt_>>я ничего не путаю, именно ты собрался в рукопашную писать модели, пользуясь выразительностью языка (тм)
НС>И при чем тут наследование? Наследование в том же REST — редкостный геморой.
не трогаем пока рест. у одной стороны все начинается с генератора, у тебя с модели. вот и расскажи, как ты модель дефинируешь. раз наследование геморой, всякие created_by, date_modified в ручную в каждую табличку прописываешь или что ?
Gt_>>по мне, так очень необычный подход.
НС>Ну это по тебе. А так очень распространенный подход.
ну как минимум в этой теме ты единственный такой. остальные тут явно прогнулись под моду DSL.
Здравствуйте, ·, Вы писали:
НС>>Большая. Если ты прикрутишь еще и рукопашный OpenAPI, разметка asp.net никуда не денется. ·>Разметка может сгенерироваться. Например, если генерировать java по openapi для spring boot
Опять пошли по кругу.
·>Ты сам придумал генерацию нескольких моделей по одному описанию.
4. то же описание из 2 используем для генерапции клиентов на Java/C#/JS.
Оно и не должно. Потому что код на C# — первичен, а не наоборот. Для любителей писать спеку openapi руками есть другие инструменты.
·>Вот вы и мучаетесь.
Здравствуйте, Gt_, Вы писали:
НС>>И при чем тут наследование? Наследование в том же REST — редкостный геморой. Gt_>не трогаем пока рест.
Gt_> у одной стороны все начинается с генератора, у тебя с модели. вот и расскажи, как ты модель дефинируешь. раз наследование геморой, всякие created_by, date_modified в ручную в каждую табличку прописываешь или что ?
Code first? Не, не слышал.
Если что, я не сторонник использования code first в случае БД. Но не по причинам, озвученным здесь, а потому что куда чаще схема БД есть до написания кода. Отсутствие необходимости в свойствах в языке тут никаким боком.
Gt_>>>по мне, так очень необычный подход. НС>>Ну это по тебе. А так очень распространенный подход. Gt_>ну как минимум в этой теме ты единственный такой. остальные тут явно прогнулись под моду DSL.
НС>Code first? Не, не слышал. НС>Если что, я не сторонник использования code first в случае БД. Но не по причинам, озвученным здесь, а потому что куда чаще схема БД есть до написания кода. Отсутствие необходимости в свойствах в языке тут никаким боком.
в сухом остатке ты лишь на форумах рассуждаешь "выразительности языка" (тм), а когда доходит до дела, ты вспоминаешь про орм и засовываешь эту выразительность подальше. тупо пишешь руками каждое поле каждой табличке в модели руками, повторяя одни и те же поля в каждой табличке, нарушая принципы DRY. при этом изображаешь непонимание при вопросах с чуть более сложными сценариями. ну ок, я понял.
хорошая иллюстрация откуда пошла мода на DSL.
Здравствуйте, Gt_, Вы писали:
Gt_>в сухом остатке ты лишь на форумах рассуждаешь "выразительности языка" (тм), а когда доходит до дела, ты вспоминаешь про орм и засовываешь эту выразительность подальше. тупо пишешь руками каждое поле каждой табличке в модели руками, повторяя одни и те же поля в каждой табличке, нарушая принципы DRY.
