Пока битва ууидов кончилась. Объясните нубу - вот есть проект

на ASP.Net Core и к нему бд прикручена через EF. Как я понял, напрямую модельки из БД вытаскивать и добавлять плохо - нужно DTO? Может кто привести пример статьи, объясняющей как это сделать правильно

Говорят если модель назвать юид думать уже не надо, оно само работает

кринге

герр кринге

сперва просто делай копии моделей из базы, постепеннно у тебя они могут начать расходиться.

Если назначение сервиса - экспоузить данные из бд как есть, то почему бы и нет? OData 2 кнопки и поехали

А разве модели нельзя в json сразу и обратно? Фокус такой провернуть

у тебя там в EF циклические графы - JSON так не умеет.

[JsonIgnore] атрибут над классом который зацикливается и все работает. У меня с этим нет проблем

Это на стороне клиента так

когда у тебя идет "отмена" функционала это очень тяжело для головы

В веб проекте можно так отрубить для json зацикливание var builder = WebApplication.CreateBuilder(args); builder.Services.AddControllers().AddJsonOptions(options => { options.JsonSerializerOptions.ReferenceHandler = ReferenceHandler.IgnoreCycles; });

ты "отменяешь" вещи ради "простоты" так ли это "просто" тогда?

Вот пример ef и json

Если так можно, то почему так нельзя?

в целом это дороже выходит так делать. может тебе и легче, но суммарно компании дороже

можно что угодно. мое мнение что это - не эффективно для любых проектов кроме маленьких - слабо "упрощает" вещи, так как любые отмены в API приводят к тому что тебе кочерыжкой думать надо, тебе надо все или только часть и когда что у тебя есть. программисты не должны так много думать.

А как же то что контролер на входе принимает из FromBoby json сразу, без разрешения получается асп деселиризует.

там десериализуются только те поля которые ты указал.

Выгода только в кб трафика, по скорости разница обработки в не значительные мс идет

А ещё и хранить бинарные данные в виде колонки в реляционной БД - раковая опухоль замедленного действия. Посмотри в сторону s3/minio или на худой конец filestreams

Почему это бомба замедленного действия? Но спасибо за наводку

Ну у тебя твои интики булианы и чарчики малость оффсетами обмажутся

dba.stackexchange.com/questions/2445/should-binary-files-be-stored-in-the-database

Не обмажутся если идентификаторы в порядке

А когда их станет много, проблемочки появятся из-за индексиков в оффсетиках

спасибо почитаю

странное суждение ибо у того же чата этих индексов тоже не мало. Так и там свои уникальные id

я вообще не про скорость. это про то что у тебя если разные вещи, то лучше бы держать их разными. для мелких проектов я вообще то согласен что такой подход роляет. очень эфективно, мало форм быстро забацал и все. если потом их никто трогать сильно не будет или под снос они через пару лет пойдут. если у тебя будетт больше форм, то так или иначе у тебя начнут появляться неконсистентности в интерфейсе с базой, то ты будешь на одно поле меньше заполнять, то что-то ты только читать можешь, а что-то видеть не можешь. и вот эту разницу с моей точки зрения лучше явно выражать в классах. это скучно, но очень понижает шанс ошибиться потом.

С названием Image и не сложным проектом, такой подход эффективен и бд никогда не будет вешать ну слишком много, плюсы, доступность бд. И вообще не понял причем тут формы

API endpoints ~= экранный формы

ок, но создавая таблицы, модели. Понятно что забыть легко где что. Я сверху пишу комментарии для себя всегда, даже в маленьких проектах. На случай если нужно будет обновить или что то еще, чтобы быстро разобраться в проекте.

Там часть ответов за бд, часть за хранилище, но по сути зависит от конкретной задачи. На вкус и цвет каждому свое как говорится. Если у меня нет в проекте например такого что нужно быть расширить файловое хранилище, то бд будет лучшим решением и также для передачи картинок зачем мне делать потоковую передачу данных? Если жалкие 500кб можно отправить через буферизацию и при этом нагрузки не будет сильной даже если пользователей будет много