Используйте конструктор, чтобы установить свойства в Swagger - PullRequest
Новая
       51

Используйте конструктор, чтобы установить свойства в Swagger

0 голосов
/ 23 октября 2018

Я создаю API и использую сваггер для проверки конечных точек.У меня есть ProductDTO: 

public string ProductName { get; set; }
.
.
.
public Price Price { get; set; }

в этом DTO, я хочу использовать класс Price, который используется во всем моем коде.Класс цены выглядит следующим образом: 

public class Price
{
    public Price(decimal amount, string currency)
    {
        Amount = amount;
        Currency = currency;
    }

    public decimal Amount { get; private set; }
    public string Currency { get; private set; }
}

Но поскольку в классе Price используются частные сеттеры, я не могу установить эти значения с помощью сваггера (он имеет атрибут readonly для них).Мне очень нравится такой подход, когда есть частные сеттеры и устанавливаются значения с помощью конструктора, который, кстати, является публичным.Можно ли каким-то образом установить значения для класса Price, используя swagger, и при этом использовать свойства-установщики в свойствах?

1 Ответ

0 голосов
/ 23 октября 2018

Обновление: Мой оригинальный ответ (см. Далее ниже) состоял в том, что это невозможно, однако, это действительно зависит от библиотеки сериализации, используемой в вашем проекте.

Например, Json.NET от Newtonsoft позволяет вам устанавливать некоторые свойства вашего класса через конструктор (примечание: если ваш класс содержит более одного конструктора, примените атрибут JsonConstructorAttribute): 

public class Price
{
    [JsonConstructor]
    public Price(decimal amount, string currency)
    {
        Amount = amount;
        Currency = currency;
    }

    public decimal Amount { get; private set; }
    public string Currency { get; private set; }
}

Оригинальный ответ

Нет, это невозможно.Потому что, если вы сохраняете свои свойства закрытыми и просто инициализируете их через конструктор, ваш десериализатор не будет знать, как эти свойства должны быть сопоставлены с вашей моделью бэкэнда (DTO).

Поэтому при работе с DTO вы обычно не делаетесмотрите, как инициализируются с помощью конструктора.

Кроме того, поскольку вы используете класс Price во всем коде, вы смешиваете свою «модель домена» с «моделью представления» (= моделью, которую вы используете для связи с клиентом).) - это прагматичный подход, но не пропагандируемый в таких стилях, как DDD.В таком случае, если вам нужны разные свойства или разные модификаторы доступа для ваших свойств, вы должны создать выделенное PriceDTO, которое сопоставляется с вашей сущностью Price, но имеет общедоступные установщики и получатели.

Другой вариант - разделитьМодель, используемая конечной точкой, которая отправляет данные клиенту (через GET) из модели, которая используется конечной точкой, которая получает данные в качестве полезной нагрузки для создания или обновления объектов (через POST / PATCH / PUT).Однако это часто происходит за счет избыточности, поскольку модели в обоих случаях часто очень похожи.

...