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

НС>·>Вот это неясно. Генераторы выбирают и оптимизируют под условия. Если это rest и там принято json, то и оптимизировать в принципе нечего, тормозить будет безбожно в любом случае, зато human-friendly. А если нужна скорость, то берут protobuf или даже SBE и там всё до тактов вылизано, cache-friendly и т.п., на случай требований low-latency.
НС>Я писал не про оптимизации, а про оптимальность моделей. Реляционная модель отличается от ОО и напрямую ложится плохо. То же самое касаемо ОО и REST. В лучшем случае генераторы позволяют в полуручном режиме выходные модели допиливать, но чаще даже такой возможности нет, жри кактус.
Да всякое бывает. По ddl можно генерить код на ЯП, чтобы строить те же sql запросы с type-safety, без всякого ОО. И в случае rest то же — описываем структуру документа и генерим код, чтобы можно было удобно создавать json-документы, без всякого ОО. Какие варианты ещё в случае развесистых rest api? Строки клеить что-ли?

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

НС>·>Вот это неясно. Генераторы выбирают и оптимизируют под условия. Если это rest и там принято json, то и оптимизировать в принципе нечего, тормозить будет безбожно в любом случае, зато human-friendly. А если нужна скорость, то берут protobuf или даже SBE и там всё до тактов вылизано, cache-friendly и т.п., на случай требований low-latency.
НС>Я писал не про оптимизации, а про оптимальность моделей. Реляционная модель отличается от ОО и напрямую ложится плохо. То же самое касаемо ОО и REST. В лучшем случае генераторы позволяют в полуручном режиме выходные модели допиливать, но чаще даже такой возможности нет, жри кактус.
Да всякое бывает. По ddl можно генерить код на ЯП, чтобы строить те же sql запросы с type-safety, без всякого ОО. И в случае rest то же — описываем структуру документа и генерим код, чтобы можно было удобно создавать json-документы, без всякого ОО. Какие варианты ещё в случае развесистых rest api? Строки клеить что-ли?

Ты, видимо, об ORM говоришь, неясно причём тут оно.