Tại sao chúng ta đi MVVM trên MVC hoặc MVP trong khi giao dịch với WPF?Tại sao MVVM và lợi ích cốt lõi của nó là gì?
Chúng tôi có thêm lợi ích gì khi sử dụng tính năng này?
Chỉnh sửa:
Thành thật mà nói, hôm nay tôi đã phỏng vấn và tôi đã được hỏi câu hỏi này. Tôi trả lời như INotifyPropertyChanged, ICommand, IValue Convertor .. nhưng anh ta không hài lòng. Từ nay trở đi tôi đã đưa ra câu hỏi này
Cảm ơn trước
Tôi sẽ chỉ cho bạn một số đặc biệt hữu ích video bởi Jason Dolinger.
Xuất phát từ thế giới WinForms, việc thực hiện bất kỳ kiểu mẫu MVX nào có vẻ phức tạp hơn nó đáng giá nhưng sau khi làm việc với WPF vài năm nay, tôi có thể thành thật nói rằng tôi sẽ không xem xét bất cứ điều gì ít hơn. Toàn bộ mô hình được hỗ trợ out-of-the-box.
Trước hết, lợi ích chính là cho phép tách biệt thực sự giữa 'chế độ xem' và 'mô hình'.Điều đó có nghĩa là trong thực tế là nếu/khi mô hình của bạn cần thay đổi, nó có thể không cần xem và ngược lại.
Thứ hai, trong khi 'mô hình' của bạn có thể chứa tất cả dữ liệu bạn có thể cần trong 'chế độ xem', bạn có thể muốn trừu tượng dữ liệu đó theo cách mà 'mô hình' của bạn không hỗ trợ. Ví dụ: giả sử mô hình của bạn chứa thuộc tính ngày. Trong mô hình, nó có thể tồn tại chỉ như một đối tượng DateTime nhưng chế độ xem của bạn có thể muốn hiển thị đối tượng theo một cách hoàn toàn khác. Nếu không có 'viewmodel', bạn phải sao chép thuộc tính trong 'model' để hỗ trợ chế độ xem hoặc sửa đổi thuộc tính có thể làm xáo trộn nghiêm trọng 'mô hình'.
Bạn cũng có thể sử dụng 'viewmodel' để tổng hợp các phần của mô hình tồn tại trong các lớp/thư viện riêng biệt để tạo điều kiện giao diện thông thạo hơn cho 'chế độ xem' để xử lý. Đó là rất không chắc rằng bạn sẽ muốn làm việc với dữ liệu trong mã của mình giống như cách người dùng muốn hoặc sẽ muốn dữ liệu đó được hiển thị cho họ.
Trên hết, bạn nhận được hỗ trợ cho liên kết dữ liệu hai chiều tự động giữa 'chế độ xem' và 'chế độ xem'.
Có thực sự là một bó toàn bộ các công cụ bổ sung mà tôi có thể đập vào nhưng Jason nói nó là xa hơn tốt hơn nên tôi có thể khuyên tôi xem video. Sau một vài ngày làm việc như thế này, bạn sẽ tự hỏi làm thế nào bạn đã bao giờ có được mà không có nó.
Chúc may mắn.
Video đó của Jason hoàn toàn là phần giới thiệu hay nhất về MVVM mà tôi từng thấy/đọc. Và mã nguồn có thể được tìm thấy ở đây http://blog.lab49.com/archives/2689 –
Nướng trong hỗ trợ cho ICommand và INotifyPropertyChanged là hai lợi ích lớn nhất. Sử dụng MVVM giúp bạn dễ dàng kết nối các lệnh và cắm dữ liệu vào giao diện người dùng WPF. Mọi thứ chỉ hoạt động.
Thành thật mà nói, hôm nay tôi đã có một cuộc phỏng vấn và tôi đã được hỏi câu hỏi này. Tôi cũng trả lời gần như cùng một điều như INotifyPropertyChanged, ICommand, IValue Convertor .. nhưng anh ta không hài lòng. Do đó, tôi đã đưa ra câu hỏi này. –
WPF có databinding tốt hơn so với bất kỳ khuôn khổ UI khác, mà MVVM sẽ ngang bướng không
MVVM cung cấp đơn vị testability và tuyệt vời view-thuyết bất khả tri, mà làm cho nó một điều tốt để sử dụng
Đây là những mỏ cụ thể để MVVM
Hai mẫu khác thực sự tách biệt về các mối quan tâm mà chúng giải quyết. Bạn có thể sử dụng MVVM với MVP và MVC (hầu hết các mẫu tốt ra có làm một số hình thức này).
Thực tế, MVP (w/Passive View, chứ không phải là một bộ điều khiển giám sát) thực sự chỉ là một biến thể của MVVM, theo ý kiến của tôi.
2 và 4 là đúng cho MVC hoặc MVP cũng như MVVM. –
Vâng ... Tôi bỏ qua các mẫu đó vì chúng thực sự giải quyết một khía cạnh hơi khác so với một ứng dụng điển hình. Tôi đã chỉnh sửa câu trả lời của tôi để bao gồm điều này. –
+1 Sự hiểu biết dễ hiểu và dễ hiểu –
Khả năng mã XAML để dữ liệu, cũng như sự tồn tại của trình kích hoạt sẽ phá vỡ mẫu MVP và MVC.
Tôi thấy rằng MVVM không phải là lợi ích, mà là nghĩa vụ đối với những người muốn sử dụng các tính năng tuyệt vời của WPF.
WPF được xây dựng rất nhiều với sự ràng buộc dữ liệu ở lõi, để cho phép tách giao diện người dùng khỏi Mô hình. Nhưng cách dữ liệu ràng buộc là về mặt kỹ thuật thực hiện trong WPF là hơi đặc biệt, vì nó gắn liền với các lớp học như:
Bởi vì điều này bạn chỉ có thể không thực sự viết một mô hình theo cách bạn muốn sử dụng công nghệ .NET chuẩn. Ví dụ, TreeView WPF gần như không thể sử dụng w/o bằng cách sử dụng ràng buộc dữ liệu và các mẫu. Bạn chỉ có thể không cư nó đơn giản như bạn sẽ từ một mô hình chung trong Winforms ví dụ. Nó phải bị ràng buộc vào một mô hình phân cấp bằng cách sử dụng ObservableCollection để biểu diễn con của nút. Vì vậy, hãy nói V đại diện cho mã XAML và mã sau đối tác của nó (vì vậy nó gắn với WPF như một công nghệ), và giả sử M đại diện cho mô hình của bạn (vì vậy nó không gắn với công nghệ UI WPF).
Vâng, bạn sẽ không bao giờ có điều này hoạt động bình thường dưới WPF chỉ với những V & M.
Bạn phải thêm một cái gì đó giữa hai người. Cái gì đó tương thích với WPF và hiểu mô hình của bạn. Cái gì đó nói DependencyProperty, ObservableCollection và INotifyPropertyChanged. Đó là những gì được gọi là VM.
Là một lưu ý phụ, thay thế cho MVVM là tạo kết hợp V & M (w/o VM) với M tương thích với WPF nhưng vẫn có độc lập UI hợp lý. Trong lịch sử, ObservableCollection đã được trong hội đồng WindowsBase.dll (đã được vận chuyển với WPF), do đó, nó thực sự trông kỳ lạ để ràng buộc một mô hình chung chung với một cái gì đó gắn liền với một công nghệ giao diện người dùng. Nó đã được chuyển trở lại System.dll từ. Thậm chí sau đó, đôi khi rất khó để giữ một mô hình VM thuần túy với tinh chỉnh M đặc biệt cho WPF ...
Có đồng ý với hầu hết những gì bạn nói nhưng dữ liệu của WPF hoạt động tốt trong mã phía sau cũng như một máy ảo. OC, INPC và DP đều hoạt động tốt mà không có MVVM. Sức mạnh thực sự của WPF nằm trong databinding không MVVM. Chúng tôi xây dựng cả MVVM & mã phía sau, cả hai đều có dữ liệu xuất sắc. –
Tôi luôn xem MVVM như một biến thể của MVC. –