Thông báo cho người dùng cuối về ngoại lệ trong Winforms-MVP và WPF-MVVM

Question

Trong nửa năm của Winforms-MVP, tôi đã thiết kế chiến lược xử lý ngoại lệ sau đây. Tôi có một lớp Presenter trừu tượng cơ bản với một số phương thức Execute lấy một đại biểu làm tham số đầu vào (chữ ký thay đổi). Tương tác giữa View và Presenter được thực hiện thông qua các sự kiện (input) được định nghĩa trong IView và bằng cách thiết lập các thuộc tính public (output) hoặc các phương thức gọi được định nghĩa trong IView và được thực hiện bởi View. Mỗi trình xử lý sự kiện trong trình trình bày gọi một trong các phương thức Execute cung cấp phương thức này với việc thực hiện cụ thể.

Trong phương thức thực thi, tôi có một số khối bắt giữ cho các ngoại lệ rất có thể xảy ra (chủ yếu là do một số vấn đề trong các thành phần bên ngoài được sử dụng rộng rãi). Mỗi trường hợp ngoại lệ này dừng việc thực hiện thao tác hiện tại, đang được ghi lại và hiển thị cho người dùng với lời giải thích có ý nghĩa bằng cách gọi phương thức của View.

Cách đây không lâu (trên thực tế cách đây không lâu) Tôi bắt đầu học WPF-MVVM mà từ cái nhìn đầu tiên dường như có nhiều điểm chung với MVP. Tôi đang tìm kiếm một số lời khuyên hữu ích liên quan đến chiến lược xử lý ngoại lệ ở đó (chủ yếu thông báo cho người dùng về các vấn đề), nhưng câu hỏi này khó tìm kiếm nói chung - ý tôi là nhiều, nhưng chủ yếu là về nguyên tắc. Tôi đã tìm thấy hơn 20 ví dụ về "xử lý" ngoại lệ chưa được xử lý trong app.xaml.cs, tất cả đều rất hay, nhưng hãy nói cho tôi biết - nếu bạn biết chính xác các ngoại lệ có thể làm hỏng ứng dụng, bạn sẽ không xử lý chúng sớm hơn một chút (ngay cả khi bạn buộc phải đóng ứng dụng của mình)? Tôi không có cách nào để bắt được tất cả các ngoại lệ có thể xảy ra. Khá nhiều ngoại lệ do các vấn đề mạng gây ra, không có sẵn cơ sở dữ liệu tạm thời và do đó sẽ không được đóng ứng dụng mà không có biểu tượng lỗi đáng sợ cho người dùng bình thường cơ hội lặp lại yêu cầu của mình.

Vì vậy, với tư cách là một thử nghiệm, tôi đã thử hầu như giống như tôi đã mô tả trước đó - Tôi đã tạo sự kiện trong ViewModel để chuyển đổi ngoại lệ và đăng ký Xem với chúng. Nhưng, thẳng thắn mà nói, cách này cho tôi creep.

(Đó là một bài phát biểu rất dài, tôi biết) Câu hỏi: làm thế nào để bạn xử lý các ngoại lệ trong những gì liên quan đến việc thông báo cho người dùng khi sử dụng MVVM? Không, tôi không quan tâm đến việc xác thực dữ liệu ngay bây giờ. Bất kỳ lời chỉ trích và/hoặc tư vấn về MVP cũng được hoan nghênh.

Answer 1

Chúng tôi có một vài chiến lược khác nhau cho các loại điều kiện lỗi khác nhau trong các ứng dụng Wpf của chúng tôi.

Đối với các lỗi dự kiến ​​mà mã có thể xử lý và tiếp tục mà không thông báo cho người dùng, chúng tôi sẽ thực hiện các khối try catch bình thường. Đối với các lỗi được dự đoán nhưng dẫn đến thất bại từ quan điểm của người dùng, chúng tôi trưng ra một bộ sưu tập Thông báo trên ViewModels của chúng tôi, liên kết với một ItemsControl trên View của chúng tôi được sắp xếp theo cách tương tự với các thanh thông báo trong Firefox/IE/Chrome.Mỗi thông báo có thuộc tính thời lượng chương trình (bộ sưu tập Thông báo tự cắt bằng bộ hẹn giờ điều phối) và nút đóng trong chế độ xem để chúng có thể xuất hiện trong một khoảng thời gian cụ thể hoặc có thể được người dùng đóng một cách rõ ràng. Điều tốt đẹp về mô hình này là nó có thể được sử dụng cho các thông báo Hoàn thành, cảnh báo và ngoại lệ - và cũng có một số điều kiện có thể không biểu hiện như một ngoại lệ nhưng đó vẫn là điều kiện lỗi từ quan điểm của người dùng. Thông báo thường là sự thay thế tốt cho hộp thư vì chúng không làm gián đoạn quy trình làm việc của người dùng.

Đối với các lỗi mà chúng tôi không lường trước, chúng tôi sử dụng Red Gate SmartAssembly để nắm bắt chi tiết đầy đủ để người dùng có thể gửi chúng đến bộ phận hỗ trợ của chúng tôi để phân tích. Quan điểm của chúng tôi là bắt và tiếp tục ứng dụng của bạn sau khi ngoại lệ mà bạn không lường trước là một chiến lược rất mạo hiểm - ngăn xếp từ một ngoại lệ không mong muốn không bị bỏ ngỏ và ứng dụng của bạn sẽ bị bỏ lại ở trạng thái không nhất quán sau khi lỗi (có thể dẫn đến bất kỳ thứ gì từ giao diện người dùng lạ đến dữ liệu bị hỏng) và có thể có các tác dụng phụ không thể dự đoán được. Nó không phải là một trải nghiệm người dùng tuyệt vời để có một sự cố ứng dụng, nhưng đó là một kinh nghiệm tồi tệ hơn đáng kể để có nó bị hỏng dữ liệu vì một trạng thái unanticipated gây ra bởi một lỗi đã bị bỏ qua bởi các ứng dụng. Chiến lược của chúng tôi là thu thập càng nhiều chi tiết về sự cố để người dùng biết rằng chúng tôi nghiêm túc giải quyết vấn đề và chúng tôi sẽ khắc phục sự cố trong bản cập nhật trong tương lai - thay vì chỉ tiếp tục và hướng đến các vấn đề có thể tồi tệ hơn.

Answer 2

Tôi đồng ý, việc xử lý ngoại lệ trong app.xaml.cs của bạn không tốt, vì về cơ bản là quá muộn!

Đối với các hoạt động mà ngoại lệ tiềm năng tương đối cao (xử lý tệp, mạng IO), hãy đảm bảo rằng bạn chủ động bắt ngoại lệ. Tôi tiếp xúc này để xem trong một trong hai cách:

1. Đối với các lỗi mà chỉ ra một số vấn đề lâu dài, vấn đề về mạng ví dụ, tôi tiếp xúc với một 'ErrorState' poperty
2. Đối với các vấn đề thoáng qua, không tìm thấy file ví dụ, phơi bày một sự kiện.