Часто в ендпойнте пишут либо
Create(PersonContract person)
Create([FromBody]Person person)
Create(PersonDto person)

Вопрос если на вход приходит урезанная версия Person что вы используете и почему?

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

ET>Часто в ендпойнте пишут либо
ET>Create(PersonContract person)
ET>Create([FromBody]Person person)
ET>Create(PersonDto person)

ET>Вопрос если на вход приходит урезанная версия Person что вы используете и почему?

Что значит "урезанная"? Для создания урезанная или для обновления?

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

ET>Часто в ендпойнте пишут либо
ET>Create(PersonContract person)
ET>Create([FromBody]Person person)
ET>Create(PersonDto person)

ET>Вопрос если на вход приходит урезанная версия Person что вы используете и почему?


Если речь о .net, то:

Можно просто просто не биндить поля (атрибут Bind)
или вызывать Controller.TryUpdateModelAsync

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

С>Здравствуйте, e.thrash, Вы писали:

ET>>Часто в ендпойнте пишут либо
ET>>Create(PersonContract person)
ET>>Create([FromBody]Person person)
ET>>Create(PersonDto person)

ET>>Вопрос если на вход приходит урезанная версия Person что вы используете и почему?

С>Что значит "урезанная"? Для создания урезанная или для обновления?

и для создания и для обновления.

на создание есть поля которые система сама проставляет: дата создания, кто создал, откуда
на обновление может меняться 3 поля из 10 в таблице

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

ET>и для создания и для обновления.

ET>на создание есть поля которые система сама проставляет: дата создания, кто создал, откуда
ET>на обновление может меняться 3 поля из 10 в таблице

Я бы разные классы делал, базовый и от него наследовал.

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

С>Здравствуйте, e.thrash, Вы писали:

ET>>и для создания и для обновления.

ET>>на создание есть поля которые система сама проставляет: дата создания, кто создал, откуда
ET>>на обновление может меняться 3 поля из 10 в таблице

С>Я бы разные классы делал, базовый и от него наследовал.

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

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

ET>так вроде сущности базы считается не очень хорошо использовать в контролерах.
ET>мне казалось сущности базы в домене\бизнес логике. а в контролере легкие объекты типа дто

Так и делайте разные ДТО. Ну да, маппинг нужно будет писать, а как ещё.

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

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

С>>Здравствуйте, e.thrash, Вы писали:

ET>>>и для создания и для обновления.

ET>>>на создание есть поля которые система сама проставляет: дата создания, кто создал, откуда
ET>>>на обновление может меняться 3 поля из 10 в таблице

С>>Я бы разные классы делал, базовый и от него наследовал.

ET>так вроде сущности базы считается не очень хорошо использовать в контролерах.
"Не очень хорошо" это когда кода больше и\или ошибок больше. А все остальное вполне нормально.

ET>мне казалось сущности базы в домене\бизнес логике. а в контролере легкие объекты типа дто
DTO имеет смысл если логика интерфейса отличается от хранимой структуры данных. Но в большинстве учетных задач это не так.