Как я могу сделать Обработка ошибок в приложении Windows Form MVC / MVVM - PullRequest
2 голосов
/ 08 марта 2011

Я создаю приложение, используя шаблон, похожий на MVC.Ситуация следующая: в контексте модели вносятся изменения в связанный репозиторий.Если изменение вызывает исключение, как правильно представить пользователю информацию об ошибке?В предыдущей версии моей программы, когда у меня была организация кода spaguetti (модель, представление, контроллер перекрываются), запуск сообщения, сообщающего пользователю об ошибке, не был странным, потому что я делал почти все из представлений.Теперь в этой новой версии я хочу сделать все правильно, поэтому я думаю, что плохо делать все, что имеет визуальное представление на уровне модели.Некоторое время назад я спрашивал, как правильно фиксировать исключения.Особая мысль, о которой я говорил, заключалась в том, чтобы масштабировать исключения из внутреннего кода до верхнего уровня против захвата их в самом верхнем уровне.Почти все ответы были такими, что не являются хорошими исключениями масштаба подхода (захват и повторный бросок для захвата ответственной сущностью), и их лучше захватывать на самом верхнем уровне.Так что у меня в голове этот конфликт.Я думал, что неизбежно поддерживать разделение интересов в масштабе, но это противоречит этим предыдущим советам.Как я могу продолжить?

1 Ответ

2 голосов
/ 08 марта 2011

Распространенным шаблоном является наличие общего места для ошибок в существующей модели.

Один из простых способов сделать это состоит в том, чтобы все классы вашей модели наследовали от базового класса модели, имеющего свойство типа IEnumerable<ErrorBase>, или другого выбранного вами типа.

Затем в своем докладчике вы можете проверить сбор ошибок и отобразить при необходимости.

Что касается появления исключений, то подход, который я использую (почти независимо от того, какой тип приложения я создаю), заключается в том, чтобы обрабатывать исключения только на более низких уровнях, если вы собираетесь делать какую-то специальную запись (например, запись важных локальных записей). переменные), или если вы можете сделать что-то умное с этим исключением. В противном случае, пусть пузырь.

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

Самые верхние слои не «ответственны» за всплывающие исключения, они просто отвечают за то, чтобы те не показывались конечным пользователям (или клиенту веб-службы, или какому-либо другому) в форме, которую вы наделили не хочу, чтобы они ... другими словами, вы «представляете» их соответствующим образом.

Помните, разделение интересов - это парадигма, которой вы должны следовать, как правило, а не эдикту, который владеет всем. Так же, как и у дырявых абстракций, есть парадигмы с утечками. Делайте то, что имеет смысл, и не слишком переживайте по этому поводу. :)

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