Использование IDataErrorInfo или любого аналогичного шаблона для распространения сообщений об ошибках

Question

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

В настоящее время я думаю о том, как проверить ошибки конфигурации в приложении. Доступны различные параметры, и один из них, который использовался ранее, - это интерфейс IDataErrorInfo. Я не очень доволен тем, как выглядит эта реализация, не потому, что она не работает, потому что она работает, просто я не полностью согласен с фактической реализацией. Я искал этот сайт (все 52 связанных вопроса) и другие, чтобы понять, почему Microsoft решила, что использование ключевого слова «this» с индексом было бы хорошей идеей. Обычно он используется для индексации элементов в коллекции, и даже если принять во внимание, что классы, которые я реализую, представляют собой набор ошибок, я не совсем согласен с тем, что ключевое слово «this []» должно неявно использоваться для их тестирования. (Примечание: означает ли это, что у пользовательского класса коллекции не может быть собственных ошибок конфигурации?) Почему это не вызов метода типа «TestErrorState (string propertyname)» или даже индексированное свойство? И как часто это «строка ошибки {получить; } ”На самом деле используется? Для меня это выглядит как «взлом» и не очень прост в использовании.

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

Пожалуйста, дайте мне знать, где я могу найти хорошую информацию о том, почему IDataErrorInfo такая, какая она есть. И если вы можете дать мне хорошую идею о том, как использовать режимы ошибок, которые распространяются через иерархию объектов, это было бы просто великолепно! Когда я говорю «распространять», я не имею в виду исключение, так как это похоже на событие, просто когда объект запрашивается на предмет ошибок конфигурации, он должен также запрашивать ошибки у всех своих дочерних элементов, а затем передавать также сообщения об ошибках дочерних элементов.

Answer 1

Члены интерфейса IDataErrorInfo обычно не имеют никакого значения вне самого интерфейса, потому что вы вряд ли когда-нибудь захотите сами запросить ошибки проверки сущности.Интерфейс IDataErrorInfo предназначен для использования технологиями пользовательского интерфейса, такими как MVC и WPF.

Поскольку нет необходимости вызывать свойство Error или this[string] напрямую, как обычно могут IDataErrorInfo члены.быть реализовано в явном виде.Это препятствует тому, чтобы они появлялись в самом классе, и позволяет вам реализовать свой собственный, более полезный, индексатор this[].

Я согласен, что наличие индексатора на этом интерфейсе, вероятно, было не лучшим дизайном,но IDataErrorInfo, вероятно, в любом случае спроектирован с явной реализацией, поэтому это не имеет большого значения.

Вот пример того, как реализовать IDataErrorInfo явно.

Answer 2

Я не уверен, что вы используете MVVM, но похоже на это.Я согласен, что this[] накладывает дополнительные ненужные ограничения на реализацию, хотя это могло бы быть GetError(string propetyName).Я думаю, что это похмелье COM, и этот интерфейс доступен через COM, но будет проверять и подтверждать.

На практике я никогда не обнаруживал, что это [] вызывает какие-либо проблемы.Это почти никогда не будет реализовано в коллекции, поскольку для привязки коллекций обычно используется ObservableCollection, и будут реализованы только отдельные элементы IDataErrorInfo.

Если у вас есть иерархия (например, Customer и Orders), вы обычно реализуете представлениемодель для обоих и модель представления заказа будет иметь ссылку на свою родительскую модель представления клиента, чтобы она могла распространять ошибку.Сценарии у меня были, этот подход всегда работал.Если у вас возникла конкретная проблема, опубликуйте новый вопрос или обновите свой.