Какова лучшая практика для обработки исключений в Silverlight?

Question

В ASP.NET я обычно регистрирую исключения на стороне сервера. В формах Windows я могу либо регистрировать исключения на стороне сервера, либо записывать в файл журнала на клиенте. Silverlight, кажется, подходит где-то посередине.

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

Answer 1

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

Я бы предложил выставить метод "LogEvent (..)" на веб-службе на стороне сервера (возможно, у вас уже есть), который затем будет выполнять те же действия, что и в ASP.net

Вот видео об основных вызовах веб-службы в Silverlight, если вы еще этого не сделали http://silverlight.net/learn/learnvideo.aspx?video=66723

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

Надеюсь, это поможет!

Answer 2

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

Answer 3

Используйте Изолированное хранилище, доступное для приложения Silverlight . Вы должны хранить здесь свой журнал.

Затем вы можете разработать механизм отправки журнала пользователя в веб-службу, например службу отчетов об ошибках Windows.

Answer 4

Я бы сказал, что Silverlight намного лучше подходит для ASP.NET модели. У вас есть сервер, который обслуживает веб-страницу. Объект (приложение Silverlight) на странице пингует службу данных для извлечения данных и их отображения.

Весь доступ к данным происходит на стороне сервера, и не имеет значения, используются ли данные для создания страниц ASP.NET на сервере или отправляются необработанными в RIA для отображения. Я регистрирую любые сбои в службе данных на стороне сервера (журнал событий работает нормально) и не разрешаю передавать какие-либо исключения в WCF. Когда клиент не получает ожидаемые данные (он получает нулевую коллекцию или что-то подобное), он отображает общую ошибку доступа к данным для пользователя. Возможно, нам придется расширить это в ближайшее время, чтобы передать немного больше информации (различие между отказом в доступе / отсутствующей базой данных / сбоем инфраструктуры / внутренней ошибкой / и т. Д.), Но мы не планируем передавать сообщения об ошибках исключения клиенту.

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

Answer 5

Это очень сильно зависит от типа приложения, которое вы разрабатываете.

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

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