Необходимость использования разных DTO на ресурсе web api

Question

У меня есть пара DTO, которые я использую в WEB API, и я заметил, что снова и снова использую одни и те же свойства.

Например,

public class Response
{
public int Id {get;set;}
public DateTime CreatedOn {get;set;}
public string Name  {get;set;}
public string Code {get;set;}
}
public class InsertRequest
{
public string Name  {get;set;}
public string Code {get;set;}
}

Действительно линеобходимость указать InsertRequest для ресурса, поскольку DTO обрабатываются позже в коде?Это может вводить в заблуждение иметь свойство Id, доступное в коде, даже если Id не будет вставлен.

С другой стороны, если Id объявлен как обнуляемый, это может вводить в заблуждение, поскольку Id в Response не должен быть обнуляемым, поэтомуЯ сомневаюсь, что эти два запроса должны быть разделены или все они должны быть в одном, представляющем ресурс?

Answer 1

Ситуация, которую вы описываете, довольно часто встречается в ситуациях, когда вам нужно создавать / обновлять сущности.

Я бы порекомендовал вам оставить ваши как есть.CreatedOn не имеет смысла, когда вы хотите обновить и Id, ну, он никогда не изменится после создания, поэтому, опять же, не имеет смысла иметь его в сущности изменения.Кроме того, есть вероятность, что вы предоставите свой Id в маршруте, так что действительному объекту он все равно не нужен:

PUT против:

www.somedomain.com/entity/id

объекту не нужно поле id какон приходит из URI.

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

Еще одна вещь, я за сохранение четкого соглашения о присвоении имен, так что если одна сущность будет InsertRequest , тогда другая будет UpdateRequest.