основная проблема в реализации проверок через свойства? Пожалуйста, ведите меня - PullRequest
4 голосов
/ 08 июня 2010

спасибо за внимание и время.

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

Я имею представление о том, как я буду делать проверки перед установкой значения. но не понимаю, что делать, если переданное значение неверно. Просто не настройка не является приемлемым решением, так как я хочу вернуть соответствующее сообщение пользователю (в ярлыке в веб-форме). Мой пример кода:

private  int id;
public int Id
{
    get
    { return id; }

    set
    {
        bool result = IsNumber(value);
        if (result==false)
        {
            // What to do if passed data is not valid ? how to give a appropriate message to user that what is wrong ?
        }

        id = value;
    }
}

Мысль должна была использовать return, но это не разрешено.

Ошибка броска выглядит нехорошо, так как обычно мы избегаем появления пользовательских ошибок.

Пожалуйста, помогите мне.

спасибо в ожидании

haansi

Ответы [ 4 ]

1 голос
/ 08 июня 2010

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

«Допустимо и допустимо генерировать исключения из установщика свойств.» Рекомендации по проектированию недвижимости

Лучшие практики: выбросить исключения из свойств

Какое исключение выбрасывать из установщика свойств?

1 голос
/ 08 июня 2010

Я думаю, вам лучше перейти на другой пример, потому что:

public int Id
{
  get { ... }
  set 
  { 
      if (!IsNumer(value)) // changes to if (value>5)
      {
            //the code here will never be executed
           id = value;
      }
  }
}
0 голосов
/ 08 июня 2010

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

Как эти сообщения будут собираться, храниться и представляться? Особенно, если вы решили использовать свои занятия на веб-сайте?

Что если вы хотите подтвердить свой класс в любое другое время?

Что если вы хотите использовать те же правила при проверке на стороне клиента?

Я могу понять привлекательность получения неверного значения как можно раньше, но намного проще проверить весь класс за один вызов, такой как метод Validate (). Таким образом, вы получаете полный контроль над выполнением логики проверки.

Я бы рекомендовал вам ознакомиться с двумя основными подходами к валидации свойств:

Аннотации данных

Проверка текучести для> NET 3.0 и выше

Свободная проверка для .NET 2.0

Как аннотации данных, так и FluentValidation просты в использовании, и они могут генерировать хорошо проверенные клиентские проверки на веб-формах и выигрышных формах.

В аннотациях данных проверка добавляется в свойства с использованием атрибутов. Если вы предпочитаете, чтобы ваши классы данных были чистыми объектами передачи данных, проверка Fluent предполагает создание легко читаемых правил в классах Validator.

0 голосов
/ 08 июня 2010
  1. Если чек касается только числа (типа), то ваша собственность вполне может справиться с типом безопасности. Например. Пользователь не сможет присвоить строку свойству, принимающему int.

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

  3. Еще один вариант - сохранить все эти проверочные проверки в коллекции экземпляров (внутри одного и того же объекта). Как.

    личный список _faileValdations;

// больше кода

    set
    {
    if (!IsNumber(value))
    {
    _faileValdations.Add("Invalid value for xxx. Expected... got..");
    }
    else{
        id = value;
    }
    }

И тогда ваш графический интерфейс может в конце прочитать коллекцию FailedValidations и отобразить ее в отформатированном виде на какой-нибудь метке.

Редактировать: еще один вариант ниже.

  1. Извините, я забыл упомянуть об этом раньше.

Вы также можете использовать подход, управляемый событиями. Ваш объект может предоставить событие, подобное «ValidationFailed», и все объекты GUI могут подписаться на это событие. Объект вызовет это событие в случае неудачной проверки в установщиках.

    set {
    if (!IsNumber(value))
    {
    RaiseValidationFailed("some message");
    }
    else{
        id = value;
    }
    }

"RaiseValidationFailed" может собирать сообщение, заключать его в некоторые аргументы события и запускать событие "ValidationFailed" с сообщением. Тогда GUI может реагировать на это. {Я могу предоставить вам полный код для этого, если неясно}

...