Hướng dẫn tổng hợp cho WPF: MVVM vs MVP

Question

Tôi đang bối rối. Có thể bạn có thể giúp tôi :)

Tôi đã làm theo hướng dẫn của CAG và thấy mẫu MVP rất tự nhiên đối với tôi. Giả sử tôi có một Mô hình sẵn sàng cho UI (ví dụ: triển khai INotifyPropertyChanged), tôi sử dụng người trình bày để ràng buộc Mô hình này với chế độ xem (người trình bày biết giao diện của chế độ xem), giữ cho Code-Behind của tôi càng nhỏ càng tốt (Mô hình và lệnh) tài sản (hoặc phương pháp) hoặc các sự kiện cho điều khiển không có ICommand và trong trường hợp này ngay lập tức được giao cho người trình bày.

1. Sau một thời gian tôi đã phát hiện ra mẫu MVVM, và cho đến nay nó đã giúp tôi. Theo như tôi có thể nói trong cách tiếp cận của tôi, tôi sẽ sử dụng MVVM chỉ khi Mô hình của tôi không sẵn sàng UI. Nhưng sẽ hợp lý hơn nếu giữ người trình bày và chỉ sử dụng một Mô hình mới, tôi không hiểu mình sẽ mất gì với loại sử dụng này. Tôi biết tôi đang thiếu cái gì đó, nhưng nó là gì :).

2. Đồng thời khi Chế độ xem của bạn là chung chung và có thể xử lý nhiều loại Mô hình (chẳng hạn như trong PropertyGrid). ViewModel được khuyến khích sử dụng với DataTemplate, nhưng trong trường hợp này bạn không thể tạo một Mẫu cho từng thực thể trong Mô hình của bạn, nó chỉ cần được điều tra trong thời gian chạy, bạn sẽ đề xuất điều gì?

3. Trong khi xem Josh Smith nói về MVVM trong screencast, tôi có cảm giác rằng việc hiển thị lại Mô hình trong ViewModel đang vi phạm DRY (không tự lặp lại), có thực sự không thể tránh khỏi? nó làm tôi ngạc nhiên không ai tranh luận về nó so với ngọn lửa ADO.Net Dynamic Data metadata classes are getting nowadays.

Hy vọng đó là rõ ràng đủ

Cảm ơn

Ariel

Answer 1

Nếu người dẫn chương trình biết giao diện của cái nhìn, bạn có cần tất cả các quan điểm được sử dụng bởi một người dẫn chương trình có giao diện tương tự hoặc làm người trình bày cho mỗi chế độ xem. Với MVVM quan điểm là nhận thức của viewModel, và viewModel nhận thức được mô hình (nhưng không phải ngược lại). Điều này có nghĩa là nhiều khung nhìn có thể sử dụng một máy ảo và nhiều máy ảo có thể sử dụng một Mô hình.

Tôi không hoàn toàn chắc chắn những gì bạn đang hỏi ở điểm thứ 2 của mình. VM không phải là View (hoặc nhận thức được các khung nhìn) và đối với tôi một DataTemplate định nghĩa cách một đối tượng được hiển thị. Tôi đặt DataTemplates của tôi trong một ResourceDictionary mà chắc chắn thuộc về View. Các bit duy nhất của WPF 'stuff' trong lớp VM của tôi là các lệnh.

Tôi cần thêm một chút thông tin để trả lời điểm thứ 3 của bạn. Có lẽ nó sẽ tự trả lời nếu bạn đào sâu hơn một chút vào MVVM.

Here's a related post of mine which might help you

Chúc may mắn.

Answer 2

Ad.3. Có vẻ như bạn lặp lại chính mình bằng cách phơi bày Mô hình trong ViewModel, nhưng những gì bạn thực sự làm là trừu tượng Mô hình, để View chỉ biết về sự trừu tượng này (Xem chỉ biết về ViewModel).

Điều này là do các thay đổi đối với Mô hình sẽ không làm gián đoạn Chế độ xem. Ngoài ra, Mô hình của bạn có thể được triển khai như nhiều dịch vụ khác nhau nhận dữ liệu từ các nguồn khác nhau. Trong trường hợp này, bạn sẽ không thích View để biết về tất cả chúng, do đó bạn tạo một trừu tượng khác - ViewModel.

Answer 3

Bên cạnh các nhận xét ở trên. Tôi muốn chia sẻ một số hiểu biết cá nhân của tôi về sự khác biệt.

Thông thường trong MVP bạn có giao diện Chế độ xem, ví dụ: IView, để trừu tượng các khung nhìn thực tế và liên kết dữ liệu với các khung nhìn thực tế đó. Trong MVVM, thay vào đó, bạn thường sử dụng DataContext của một khung nhìn thực tế, ví dụ. một điều khiển người dùng XAML, để làm databinding, tương tự như IView trong MVP. Vì vậy, chúng ta hãy nói, không chính xác, ràng buộc là tương tự trên cả hai mẫu.

Sự khác biệt chính là phần Trình bày so với Chế độ xemMô hình. Mô hình khung nhìn rất khác với người trình bày là cầu nối để trao đổi dữ liệu giữa giao diện người dùng và mô hình. Đó là thực sự, như những gì tên của nó có nghĩa là, một mô hình của xem. Dữ liệu được hiển thị trong ViewModel chủ yếu cho quá trình UI. Vì vậy, từ sự hiểu biết của tôi, trong MVVM, ViewModel là một trừu tượng của các khung nhìn. Ngược lại với nó, MVP chủ yếu sử dụng IView cho các khung nhìn trừu tượng. Vì vậy, thường có rất ít lớp trong MVVM hơn MVP và do đó bạn có thể viết ít mã để thực hiện công việc tương tự trong MVVM:

MVVM: Model - ViewModel (đại diện cho quan điểm thực tế, giao diện người dùng ví dụ.) - Thực tế xem

MVP: Model - Presenter (một cầu nối để trao đổi dữ liệu giữa mô hình và giao diện người dùng) - IView (đại diện cho lượt xem thực tế, tức là UI) - Số lượt xem thực tế

Lợi thế của MVVM so với MVP chủ yếu dựa trên 2 tính năng tuyệt vời sau đây sản phẩm,

1. Comman ding trong WPF. Nó có thể được avilable trong Silverlight trong tương lai mặc dù đã có một số triển khai mà không có trong thời gian chạy Silverlight

2. DataContext trong WPF và Silverlight.

Answer 4

Về # 3, rất nhiều người sẽ sử dụng đối số "một lớp khác của indirection", nói rằng thay đổi trong mô hình sẽ không ảnh hưởng đến chế độ xem. Trong khi điều này là chính xác về mặt kỹ thuật, nó không phải là lý do thực sự để làm một cái gì đó như thế này.

Nếu bạn coi Mô hình là đối tượng mà bạn lấy lại, lớp truy cập dữ liệu hoặc dịch vụ (thường được xem là), bạn bắt đầu thấy lý do bạn cần ViewModel. Một ViewModel được thiết kế để mở rộng mô hình có hành vi mà Chế độ xem cần.

Ví dụ: Nếu bạn muốn có thể thay đổi thuộc tính và có Chế độ xem được thông báo về thay đổi này thông qua ràng buộc, thuộc tính cần tăng một số dạng NotifyPropertyChanged để chế độ xem có thể phản ứng. Đây là hành vi mà mô hình điển hình của bạn sẽ không có.

Trong ví dụ khác, giả sử bạn có một bộ sưu tập và bạn muốn gắn cờ từng mục trong bộ sưu tập với giá trị boolean khi người dùng nhấp vào dấu kiểm bên cạnh mục đó trong chế độ xem. Bạn sẽ cần một thuộc tính "IsSelected", có thể. Đây là một hành vi mà Mô hình không cần phải cung cấp.

Tuy nhiên tôi thấy bạn đến từ đâu ... Tôi chắc chắn đã gặp vấn đề với điều này lúc đầu. Lần đầu tiên tôi sao chép và dán nội dung của một mô hình vào viewmodel của tôi, dạ dày của tôi quay, nhưng bạn chỉ cần làm cho hòa bình với thực tế là cho View của bạn để làm việc, nó sẽ cần thêm chút hành vi này không cung cấp.

Không có vấn đề làm thế nào un-DRY này, buộc các loại WCF của bạn hoặc LINQ to SQL loại (hoặc bất kỳ ORM yêu thích của bạn là) để thực hiện INotifyProperyChanged là tồi tệ hơn.