Tại sao ICommand tốt hơn mã phía sau gọi VM?

Question

Tôi có một đồng nghiệp hỏi tôi tại sao anh ta phải sử dụng mẫu ICommand.

Anh ấy muốn thêm nút và sau đó tạo sự kiện cho nút đó trong mã phía sau. Sau đó, từ sự kiện, anh ấy muốn gọi một phương thức trên ViewModel.

Tôi đã cho anh câu trả lời rõ ràng: Điều này bổ sung thêm sự kết nối giữa Chế độ xem và Chế độ xem. Nhưng ông cho rằng View và ViewModel đã được ghép đôi. (Chúng tôi đặt DataContext điểm của chúng tôi đối với các ViewModel trong mã của Xem đằng sau: DataContext = new MyViewModel();

Vâng, tôi nói với ông rằng con đường của mình cho biết thêm "nhiều khớp nối", nhưng nó nghe có vẻ hơi khập khiễng, ngay cả đối với tôi

Vì vậy,. Tôi biết rằng ICommand là con đường sạch sẽ, và tôi làm theo cách đó.Nhưng những gì khác mà ICommand mua cho bạn bên cạnh việc không sử dụng một khớp nối đã tồn tại,

Answer 1

• Nó không phải về tách, nhưng làm thế nào sâu bạn có thể thâm nhập vào bên trong hệ thống phân cấp ModelView của bạn: không sự kiện bơm, nhưng sự kiện định tuyến, built-in trong khuôn khổ.

• Đó là về quản lý giao diện người dùng: Command có trạng thái (CanExecute), nếu gán lệnh cho điều khiển, nếu trạng thái của lệnh trở thành false, kiểm soát sẽ bị tắt. Nó cung cấp cho bạn cách quản lý trạng thái UI mạnh mẽ, tránh nhiều mã hóa spaghetti, đặc biệt là cho giao diện người dùng phức tạp.

Answer 2

ICommand cũng có thể cung cấp cho bạn một nơi để xử lý đồng thời hoặc không phải một nút cụ thể có thể được sử dụng ngay sau đó, điều này sẽ được xử lý thông qua phương pháp canexecute.

Answer 3

Bạn có thể ràng buộc CanExecute phương pháp của lệnh để các thuộc tính của một điều khiển, cũng là Command đóng gói một hành động một cách tốt đẹp. Theo quan điểm/kinh nghiệm của tôi, cách tiếp cận này có ý nghĩa rất nhiều vì bạn có cả điều kiện và hành động thực thi trong một trừu tượng duy nhất, điều này giúp dễ hiểu và kiểm tra hơn.

Nếu trong tương lai bạn thấy rằng hành động này được lặp lại, bạn có thể tóm tắt nó một cách dễ dàng trong ICommand tùy chỉnh của riêng bạn và sử dụng nó ở nhiều nơi.

Answer 4

Tôi có một đồng nghiệp mà hỏi tôi tại sao ông phải sử dụng mô hình ICommand .

Có vẻ như đây là một tiêu chuẩn tiêu chuẩn tại công ty của bạn (dù đã nêu rõ hoặc không nói). Điều đó nên trả lời đủ cho câu hỏi của anh ta.

Nếu tất cả mã công ty được cho là sử dụng mẫu đó, nó có thể gây ra sự nhầm lẫn đồng phát triển và thất vọng khi người khác phải gỡ lỗi mã của anh ấy.

Ngoài ra, theo ý kiến ​​của tôi, việc sử dụng ICommand nhanh hơn để phát triển/giả lập vì bạn KHÔNG CẦN có tài sản ICommand trong ngữ cảnh để chạy chương trình của bạn. Nó cho phép các nhà thiết kế giao diện người dùng của bạn (nếu bạn đủ may mắn để có chúng) hoàn thành nhiệm vụ của mình ngay cả khi bạn đang ở phía sau trong mã hóa của bạn.

Answer 5

Một điều mà tôi không thấy trong các câu trả lời trước đó là việc sử dụng ICommand sẽ khuyến khích sử dụng lại mã bằng cách cho phép cùng một hành động được sử dụng bởi các thành phần GUI khác nhau.Ví dụ, nếu tôi có một lệnh sẽ dẫn đến việc mở một cửa sổ và lệnh đó có thể được gọi trong ba hoặc cho các màn hình khác nhau trong ứng dụng, việc triển khai ICommand cho phép tôi xác định logic đó ở một nơi duy nhất. Với trình xử lý sự kiện mã-đằng sau, tôi phải sao chép và dán mã dự phòng, vi phạm DRY (hoặc người nào khác, tôi phải cuộn triển khai của riêng mình bằng cách trừu tượng ra một lớp, tại thời điểm đó, tôi cũng có thể sử dụng Tôi ra lệnh).