IDataErrorInfo и проверка свойства объекта

Question

Поскольку я пытаюсь изучить WPF, я все чаще вижу использование интерфейса IDataErrorInfo для привязки ошибки к интерфейсу. Моя проблема заключается в том, что я обычно помещаю проверку данных в установщик свойства, а не в метод, подобный IDataErrorInfo.this [string columnName] ... Вот наш блог , который я обнаружил, который сделал меня смущают.

Каков хороший способ перейти в .Net 3.5 для проверки объекта данных? Нужно ли реализовывать проверки в методе, вызываемом сеттером и IDataErrorInfo? Или просто IDataErrorInfo? Или в сеттере вызвать IDataErrorInfo?

Пример: у меня есть строка имени, которая может иметь только от 3 до 50 символов. Должен ли я проверить правильность строки в установщике (что я обычно делал бы), или теперь я могу просто использовать метод IDataErrorINfo.this, проверить имя свойства и вернуть String Error, если данные имеют недостаточную длину? Я нашел более интуитивно понятным выводить ошибку в установщик и не использовать интерфейс, но в большинстве примеров я вижу использование интерфейса IDataErrorInfo.

Answer 1

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

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

Вы можете сделать это, проверив .Error в своей бизнес-логике (и убедитесь, что она null / пуста), предполагая, что вы пишете .Error, чтобы сообщить обо всех ошибках. Или аналогичный Validate() метод.

Answer 2

Я считаю, что IDataError обеспечивает гораздо более богатый пользовательский опыт. Как сказал Марк, это позволяет меньше прерываний, особенно при редактировании сетки, например. список объектов Customer.

Я рекомендую вам скачать фреймворк CSLA.net с www.lhotka.net , разработанного Роки Лоткой (он является автором бизнес-объектов Expert C # 2008). Эта структура поддерживает правила проверки, и каждый бизнес-объект реализует IDataError. Каждый раз, когда свойство изменяется, правила для этого свойства проверяются. Если значение свойства недопустимо, состояние объекта станет InValid, вызывая исключение при каждом вызове метода Save ().

Его фреймворк также поддерживает отмену n-уровня. Когда вы начинаете редактировать бизнес-объект, делается снимок объекта (включая нарушенные правила). Поэтому, если вы решите откатить свои изменения, состояние объекта вернется в предыдущее состояние - даже нарушенные правила!