Trong MVVM, ViewModel hoặc View có chịu trách nhiệm tạo các khung nhìn mới không?


11

Trong ứng dụng WPF của tôi, tôi muốn tạo một giao diện mới. Tôi nên làm điều đó ở đâu - trong ViewModel hoặc Model ?

Ứng dụng này là một công cụ giống như một cửa sổ (rất đơn giản bây giờ) với một nút "gửi". Trong trường hợp nếu một trong các hộp kiểm được chọn, cửa sổ mới sử dụng cùng ViewModel sẽ bật lên để hỏi người dùng về một số chi tiết bổ sung. Đối với mục đích của câu hỏi này, chúng ta hãy chỉ xem xét cách tiếp cận cửa sổ mới mà không xem xét các cách tiếp cận khác như bảng hiển thị / ẩn.

Lý tưởng nhất là trong View không nên có bất kỳ mã nào. Ngoài ra, vì Chế độ xem không có bất kỳ logic nào trong đó, ban đầu VM sẽ cần kiểm tra xem có cần tạo chế độ xem mới hay không và - khi đó - trả lại trách nhiệm này cho Chế độ xem, dẫn đến phình to mã.

Mặt khác, việc tạo chế độ xem mới trong ViewModel vi phạm nguyên tắc rằng ViewModel không nên biết gì về Chế độ xem.

Vì vậy, tốt hơn là tạo các chế độ xem mới trong View hoặc ViewModel?


1
Tôi không thực sự hiểu câu hỏi của bạn. "Trong View hoặc ViewModel" nghĩa là gì? ViewModels không tạo ra các khung nhìn và các khung nhìn chắc chắn không tự tạo ra.
Robert Harvey

1
Ý tôi là lớp nào trong số các lớp này sẽ chịu trách nhiệm tạo ra các khung nhìn mới - tín hiệu để làm điều đó phải đến từ đâu đó khi hành động xảy ra. Tôi đã loại trừ hoàn toàn mô hình khỏi câu hỏi này, vì nó hoàn toàn không biết gì về frontend.
Mac70

Có lẽ tôi không hiểu chính xác câu hỏi của bạn, cả hai đều không nên can thiệp vào quan điểm của bạn. Nếu bạn muốn tạo chế độ xem mới trong viewModel của mình, có lý do nào khiến bạn không sử dụng khung trong xaml để thay đổi nội dung Window với một ràng buộc với viewModel hiện tại của bạn không?
Siobhan

Câu trả lời:


8

Tôi sử dụng tiêm phụ thuộc và IViewFactorytiêm vào mô hình xem để tôn trọng cả hai ràng buộc.

Một ProductViewModel(ví dụ) gọi this.viewFactory.Show("Details", this)để mở ProductDetailsViewvới chính nó như ProductViewModel. Nó cũng có thể mở một khung nhìn dựa trên mô hình khung nhìn khác với this.viewFactory.Show<ClientViewModel>().

Việc triển khai (thực tế có một số cho WinForms, Windows Wpf đơn giản, trình bao Wpf với các tab, ...) dựa trên một StructureMapquy ước. Các khung nhìn chỉ định mô hình khung nhìn của chúng thông qua một IView<ProductViewModel>giao diện.

Vì vậy, mô hình khung nhìn không biết gì về chế độ xem ngoại trừ vai trò của nó (chế độ xem mặc định, chế độ xem chi tiết, ...) và chế độ xem không chứa mã để tạo chế độ xem khác. Ngoài ra, các mô hình khung nhìn nằm trong một cụm riêng biệt không tham chiếu bất kỳ cụm Wpf nào.


7

Câu trả lời lý thuyết

Nếu bạn có một ViewModel, các hành động có hiệu ứng mỹ phẩm (ví dụ: làm nổi bật một mục trên di chuột) là công việc của View, trong khi các hành động có hiệu ứng "thực" (ví dụ: sinh ra một cửa sổ mới) là công việc của ViewModel.

Như vậy, tạo một cửa sổ mới là một công việc cho ViewModel. Tuy nhiên, cả Chế độ xem và không ViewModelnên biết chính xác cách tạo Cửa sổ, đó không phải là một phần trách nhiệm của họ và thuộc về một lớp khác.

Bạn có thể lập luận rằng việc tạo một cửa sổ mới là một công việc cho View. Mặc dù tôi không đồng ý, nhưng có rất ít giá trị trong một cuộc tranh luận như vậy, bởi vì trong thực tế, đó không phải là ngày tận thế nếu bạn đặt mã đó vào View, và cũng không có nhiều việc phải chuyển nó sang ViewModelđiểm sau . Phần quan trọng là logic để tạo một cửa sổ mới được chứa trong một lớp độc lập, thường là một loại WindowFactory. Quan điểm của MVVM, MVP, MVC, v.v. là bạn có các lớp với ít trách nhiệm và được xác định rõ. Đó là lý do tại sao bạn không thêm trách nhiệm bổ sung cho View, ViewModelhoặc Modelnếu bạn không cần.

Trong mọi trường hợp, việc tạo ra Cửa sổ thuộc về Model, bởi vì Modelthậm chí không biết rằng có một cái gì đó giống như GUI.

Câu trả lời thực tế

Đây là về một "công cụ giống như một cửa sổ với một nút" gửi "duy nhất . Vì vậy, đây là một phích cắm không biết xấu hổ cho câu trả lời liên quan của tôi: Tại sao nên sử dụng MVVM?

Để tóm tắt những gì câu trả lời nói: Giữ cho nó đơn giản. Ồ, và ghi nhớ câu trả lời lý thuyết ở trên để thực hiện khi cửa sổ nút đơn của bạn bắt đầu trở nên phức tạp hơn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.