Null vs Value Not Set

Question

Мы написали веб-сервис, который использует простой транслятор сущностей для сопоставления значений DTO с «реальными» серверными бизнес-объектами. Как часть этого упражнения. Мы столкнулись с «интересным» различием между явно установленными нулевыми значениями и клиентами, у которых не установлено значение.

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

Решение здесь, очевидно, является своего рода «флагом».

Внутри бизнес-объекта мы можем отслеживать состояние поля внутри, используя закрытые флаги «IsDirty», установленные в установщиках свойств, но DTO действительно только определяет интерфейс, так что это означает предоставление этих данных для общего доступа. Это оставляет ряд вариантов реализации. Язык C # (такой статически типизированный), так что ...

1. Мы могли бы выставить флаг "IsSet" для каждого свойства?
2. Мы могли бы выставить каждое свойство как класс, который имеет свойства .Value и .IsSet? и т. д.

Как бы вы решили выставить эти "флаги" в Договоре о данных? Что бы вы здесь сочли лучшей практикой для этого?

Любые мнения по этому поводу будут с благодарностью.

Answer 1

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

public class DtoData<T> 
{
  T data;
  bool IsSet { get; private set; }
  T Data 
  { 
    get { return data; }
    set { data = value; IsSet = true; } 
  }
}


public class XyzDto 
{
  // only private setters, initialize in constructor
  DtoData<int?> SomeInt { get; private set; }
  DtoData<string> SomeString { get; private set; }
}

Это имеет некоторые недостатки, поэтому. Например, что все ваши данные упакованы в ссылочный тип, поэтому ссылка на DtoData все еще может быть нулевой, вам необходимо создать их в конструкторе. И трудно сделать значения доступными только внутренними или защищенными.

---

Лично я бы попытался избежать этой проблемы. Почему «не определено» действительно существует? Отправляете ли вы разногласия, неполные Dtos или откуда они? Эта проблема может возникать с фильтрами, где вам нужна разница, если вы фильтруете поле на ноль или не фильтруете его вообще. Но для таких сценариев вам все равно нужен специальный класс «field-filter».

Answer 2

Использование класса для каждого значения свойства будет более масштабируемым, чем необходимость объявления bool для каждого свойства. Это также позволит вам выбрать, какие свойства можно оставить пустыми и / или установить в ноль.

Answer 3

В общем, здесь вы говорите о значении по умолчанию, которое отличается от любого значения, которое может установить пользователь. Так что просто укажите это; установите значение по умолчанию на значение, которое не находится в допустимом диапазоне значений, которые может установить пользователь. Таким образом, если значение является значением по умолчанию, вы знаете, что оно не было установлено; если значением является что-то другое, вы знаете, что пользователь возился с ним. Просто потому, что одно из устанавливаемых пользователем значений является нулевым, кажется, отбрасывает вас; просто считайте, что это одно из множества пользовательских значений; сделать весь диапазон переменной немного большим набором с одним дополнительным значением по умолчанию. Это должно решить вашу проблему.

Answer 4

Я сталкивался с этой проблемой раньше. Вы можете обойти это, введя некоторое значение по умолчанию при построении DTO, но это не идеально. Я написал в блоге более подробно здесь , это может помочь кому-то понять проблему дальше.