Объектная модель > Действия с репозиториями и сущностями > AddError, AddInformation, AddWarning – валидация

Валидацию рекомендуется добавлять:

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

•строгую валидацию, если формат вводимых данных регламентирован. Например, в карточке контрагента можно добавить проверку длины ИНН на соответствие нормам законодательства:

public virtual void TINValueInput(Sungero.Presentation.StringValueInputEventArgs e)
{
  tin = tin.Trim();
        
  /* Проверить длину ИНН. Для организаций допустимы ИНН с длиной 10 или 12 символов, для персон – 12 символов. */
  if (!System.Text.RegularExpressions.Regex.IsMatch(tin, forCompany ? @"(^\d{10}$)|(^\d{12}$)" : @"(^\d{12}$)"))
    e.AddError(forCompany ? CompanyBases.Resources.IncorrectTinLength : People.Resources.IncorrectTinLength);
      
  // Проверить контрольную цифру.
  if (!CheckTinSum(tin))
    e.AddError(Counterparties.Resources.NotValidTin);
}

В результате при вводе некорректного ИНН появляется сообщение:

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

•нестрогую валидацию, если вводимые данные дублируют существующие сущности. Например, при вводе номера входящего письма, даты и контрагента можно проверить, существует ли уже такой документ в системе:

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

Например, проверить, сколько раз используется этап согласования в одной ветке правила. Если этап используется более одного раза, то уведомить об этом сотрудника:

Пример. Проверка на то, сколько раз используется этап согласования

public override void BeforeSave(Sungero.Domain.BeforeSaveEventArgs e)
{
  if (signStages.Count() > 1)
    foreach (var stage in signStages)
      e.AddError(stage, ApprovalRuleBases.Info.Properties.Stages.Properties.Stage, ApprovalRuleBases.Resources.ManySign);
}

Перед выполнением действий необходимо проверять:

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

•присутствуют ли связанные данные. Например, если документ отправлен на согласование, то сотрудники не смогут сменить тип документа. А если документ не был подписан, то при формирования листа согласования сотруднику отображается сообщение вида:

Действие в карточке сущности можно сделать недоступным с помощью события CanExecute. Но часто недоступность действия не дает пользователю понимания, что нужно сделать для его выполнения. В этом случае действие рекомендуется оставить доступным, но при его выполнении применять валидацию. Например, если документ зарегистрирован, то при нажатии на кнопку Сменить тип в его карточке отображать сообщение о необходимости отмены регистрации документа:

Пример. Проверка на то, можно ли сменить тип документа

public virtual void ChangeDocumentType(Sungero.Domain.Client.ExecuteActionArgs e)
{
  if (_obj.RegistrationState == OfficialDocument.RegistrationState.Registered &&
      _obj.DocumentKind.NumberingType != DocumentKind.NumberingType.Numerable ||
      _obj.RegistrationState == OfficialDocument.RegistrationState.Reserved)
  {
    Dialogs.ShowMessage(SimpleDocuments.Resources.NeedCancelRegistration, MessageType.Error);
    // При возникновении ошибки выполнение действия необходимо прервать.
    return;
  }
  ...
}

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

Пример. Объявление обязательных для заполнения полей диалога

// Второй параметр метода AddSelect() указывает на обязательность заполнения поля.
var box = dialog.AddSelect(Resources.SendCounterpartySender, true, defaultBox).From(documentInfo.Boxes);