ValidationRule и поведение в WPF

Скажем, я пытаюсь реализовать часть функциональности, в которой текстовое поле позволяет пользователю вводить только целые числа. Я могу реализовать это двумя способами: используя ValidationRule, который проверяет все, что вводит пользователь, и привязывая его к текстовому свойству через XAML, или я могу создать новое поведение и прикрепить его к элементу управления (не через привязку).

Примеры XAML для обоих:

Поведение: <TextBox behaviors:DigitsOnlyBehavior.IsDigitOnly="True"/>

ValidationRule, который привязывается к свойству Text окна.

<TextBox>
    <TextBox.Text>
        <Binding RelativeSource = "{RelativeSource Mode=FindAncestor, AncestorType=Window}" Path="Text" UpdateSourceTrigger="PropertyChanged" Mode="TwoWay">
            <Binding.ValidationRules>
                <utils:RestrictInputTypeValidator Restriction="IntegersOnly" ValidatesOnTargetUpdated="True"/>
            </Binding.ValidationRules>
        </Binding>
    </TextBox.Text>
</TextBox>

Каковы преимущества и недостатки этих подходов? Когда я должен их использовать? Или это вопрос предпочтений?


c# wpf xaml behavior validationrule
person Alexander Ventura    schedule 18.07.2013    source источник
comment
Почему бы вам не использовать WPF Toolkit?   -  person HichemSeeSharp    schedule 19.07.2013

Ответы (1)


arrow_upward
0
arrow_downward

С Behaviors мне нравится и я ожидаю «позитивный» сценарий/рабочий процесс без ошибок. Фокус без ошибок. Пользователь довольно быстро понимает, что когда он набирает 'a' в текстовом поле с числовым поведением, он его не принимает, что это числовое текстовое поле, и вот как оно работает.

При валидации больше внимания уделяется ошибке. У меня может быть числовое текстовое поле, но я также не беру числа больше 100, если вы наберете «101», я дам вам знать, что это неприемлемо. Здесь основное внимание уделяется тому, чтобы направить пользователя к тому, что неприемлемо, выдав ошибку проверки.

Преимущества поведения:

  • Профилактика (вы не позволяете пользователю выстрелить себе в ногу) путем ввода неверных данных.
  • Модель остается чистой. Привязка TextBox даже не попадает в установщик, так как поведение предотвращает это, следовательно, XAML не запускается обратно с помощью PropertChanges или ValidationErrors и т. д.

Недостаток поведения:

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

person denis morozov    schedule 18.07.2013
comment
Я не совсем уверен в обоих перечисленных преимуществах поведения. Насколько я знаю, используя правило проверки, вы также можете предотвратить ввод неверных данных и сохранить модель в чистоте, не нажимая на сеттер. Я использовал правило проверки несколько раз, и у него есть все необходимые мне функции. - person guilhermecgs; 18.07.2013
comment
Единственный недостаток, который я вижу при использовании правила проверки, заключается в следующем: как в ViewModel узнать, действительны ли все поля? Вы можете решить эту проблему, используя Validation.Error=OnFieldValidationError (но это индивидуальное решение) - person guilhermecgs; 18.07.2013
comment
Если проверка не пройдена, свойство не обновляется. Таким образом, даже с ValidationRules модель остается чистой. - person Alexander Ventura; 18.07.2013
comment
ну, за исключением ошибки проверки, которая будет заполнена, и если вы запросите/запустите ее, то модель не будет чистой... - person denis morozov; 18.07.2013