Web API нужно ли иметь классы слоя ViewModels?
Когда я использую Web (MVC), я всегда создаю отдельный слой классов. Эти классы часто совпадают с классами DTO, но с такими атрибутами, как [Display(Name = "Street")]
и проверка. Но для веб-API атрибуты отображения не нужны, проверка может использоваться FluentValidation. Должен ли контроллер Api возвращать классы ViewModels или классы DTO тоже подойдут?
2 ответа
Ответ, как всегда, есть.... это зависит.
Если ваш API обслуживает несколько клиентов, приложений и т. Д., То возврат DTO является лучшим вариантом.
ViewModels специфичны для клиента MVC и должны быть уже подготовлены к отображению, то есть данные должны быть отформатированы определенным образом, некоторые поля могут быть объединены, они должны удовлетворять любым требованиям, предъявляемым к отображаемым страницам. Они называются ViewNodels по причине. Дело в том, что они редко совпадают с данными, возвращаемыми API, которые должны быть немного более общими и следовать определенному шаблону, чтобы иметь смысл для пользователей.
Если ваши ViewModels точно такие же, и у вас есть только один клиент, то вам решать, хотите ли вы создать набор дублированных классов, чтобы избежать наличия атрибутов.
Отображение из DTO в ViewModel и наоборот не совсем сложно, но этот процесс вносит еще одну сложность, еще один слой.
Не забывайте хотя бы об одной вещи. Предполагается, что DTO API возвращают данные, которые они имеют по любому объекту, независимо от требований любого пользовательского интерфейса. Требования могут измениться в любом случае, новые поля добавляются или отбрасываются. Вы, скорее всего, оставите API в покое, когда это произойдет, и просто поменяете свои ViewModels.
Ваши ViewModels относятся только к странице пользовательского интерфейса и должны содержать только те данные, которые требуются для этой страницы. Это означает, что вы можете получить несколько ViewModel для одних и тех же данных, просто требования к отображению различны для каждого.
Мой голос направлен на то, чтобы разделить ViewModel и DTO, даже если на данный момент они абсолютно одинаковы. Тонкие всегда меняются, и это одна из тех вещей, к которой вы действительно можете быть готовы.
На самом деле это зависит от архитектуры приложения, как мы хотим вернуть ответ. В этом случае да, мы можем вернуть классы DTO, но я думаю, что это не будет хорошим подходом, потому что мы должны создать отдельные классы ресурсов, которые будут отображаться с DTO, а затем возвращаться. Просто посмотрите на приведенный ниже пример:
public class CustomerDTO
{
public int ID { get; set; }
public string Name { get; set; }
public int DepartmentId { get; set; }
}
public class CustomerResource
{
[JsonObject]
public string Name { get; set; }
[JsonObject]
public string Department { get; set; }
}
Предположим, у нас есть класс CustomerDTO, и мы хотим вернуть ответ в следующем формате json
{
"name":"Abc xyz",
"department":"Testing"
}
Так что в этом случае у нас должен быть отдельный класс, который будет возвращаться в качестве ответа конечному пользователю, когда я создал CustomerResource. В этом сценарии мы создадим маппер, который будет сопоставлять DTO с объектом ресурса. А также с этой реализацией мы можем тестировать ресурсы самостоятельно