Как проверить свойство пользовательского объекта в сценарии привязки данных (то есть BindingList)?

Question

Когда вы устанавливаете значение свойства, вы можете проверить его до или после обновления внутреннего значения.

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

Если после подтверждения, требуется отменить (то есть через IEditableObject ), поэтому пользователь может отменить редактирование в любое время. У нас также есть возможность либо выбросить здесь исключение, либо выставить ошибки через IDataErrorInfo .

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

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

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

Мне также не нравится, когда мои доменные объекты реализуют IEditableObject и IDataErrorInfo , INotifyPropertyChanged и т. Д. Он оставляет объект домена загроможденным дополнительными проблемами. Но это кажется неизбежным, если вы хотите поместить хороший с привязкой данных. Я мог бы создать оболочку, возможно, DTO, но я не слишком без ума от необходимости писать в основном фиктивный дополнительный код только для поддержки этих битов привязки данных.

Как вы проверяете объекты (предпочтительно в контексте привязки данных и пользовательского интерфейса)?

Answer 1

См. мой ответ на Бизнес-объекты, валидация и исключения : Я думаю Пол Стовелл идеи о валидации (суммированные в этой статье ) невероятно сильны.

Реализуя IDataErrorInfo в объектах вашего домена (и, возможно, IEditableObject и INotifyPropertyChanged), вы даете им возможность получить привязку к данным на многих технологиях презентаций .NET (Windows Forms, WPF, ASP .NET ...) без большого количества кода. Или вы можете использовать их в сценариях или пакетах (то есть, не в процессах пользовательского интерфейса) и при этом иметь возможность проверять их на соответствие бизнес-правилам: либо плавно (запросить текущее состояние объекта), либо сложным способом (при сохранении недопустимо генерировать исключение).

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

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