Cuối cùng, để làm một số phát triển Silverlight và tôi đã xem MVVM. Tôi quen thuộc với MVC và bài viết tôi đã đọc nói vì XAML, MVC sẽ không làm việc. Không có quá nhiều kinh nghiệm trong XAML rõ ràng là lý do tôi không nhận được điểm này.Lợi ích của MVVM trên MVC
Ai đó có thể giải thích lý do tại sao MVC không phù hợp và tại sao MVVM tốt hơn cho phát triển Silverlight?
Cảm ơn JD
nó một sự phân biệt rất mỏng, mà tôi có thể giải thích tốt nhất bằng cách so sánh MVC trong ASP.NET và MVVM trong WPF.
Trong ASP.NET MVC yêu cầu đến từ máy chủ web và được xử lý trực tiếp bởi Bộ điều khiển. Bộ điều khiển xác định Chế độ xem phù hợp và điền nó với Mô hình. Bộ điều khiển sau đó phát hành các trường hợp này đến hệ thống cơ bản, hiển thị kết quả cho máy khách. Bạn có thể thấy rằng Bộ điều khiển là đầu tiên và cuối cùng để hành động.
Trong MVVM, giao diện người dùng (Chế độ xem), đối mặt với người dùng và nhập trực tiếp người dùng. Trong View, các lệnh trong ViewModel (là DataContext của View) được kích hoạt bởi hoạt động này. Kiểm soát các luồng tới ViewModel, giải thích những gì mà View đã gửi và chuẩn bị các Mô hình của nó. Sau khi kiểm soát quay trở lại Chế độ xem, bản cập nhật sẽ tự động cập nhật theo các thay đổi trong Mô hình. Nếu một View mới là bắt buộc, ViewModel sẽ truyền đạt điều này với NavigationService (hoặc bất kỳ phương thức điều hướng nào mà ứng dụng của bạn sử dụng), đó là sự xem xét của các thành phần Window hoặc Frame - UI. Bạn có thể thấy rằng ViewModel không phải là đầu tiên và cuối cùng để hành động; View có vai trò lớn hơn nhiều so với MVC.
Kiến trúc của WPF/Silverlight là lý do tại sao mọi thứ được thực hiện theo cách này. Các cơ sở hạ tầng lệnh, ràng buộc và điều hướng không thể được điều khiển/thay thế bởi Controller; chúng được tích hợp chặt chẽ với giao diện người dùng. Vì vậy, Bộ điều khiển phải ngồi bên dưới Chế độ xem và có vai trò thụ động hơn.
Cảm ơn, lời giải thích tuyệt vời. Điều đó đã làm sáng tỏ một vài nghi ngờ. Nhờ mọi người khác trả lời. –
Tôi nghĩ ý tưởng là MVVM là tốt hơn phù hợp với XAML so với MVC. Nói MVC 'không phù hợp' là một chút phóng đại.
Và tại sao MVVM lại tốt hơn? Chủ yếu là do sự ràng buộc dữ liệu tuyệt vời và ràng buộc lệnh trong XAML. Xem this article.
MVVM được thiết kế chủ yếu là do XAML và để làm cho ràng buộc dữ liệu trở nên đơn giản hơn, nó rất giống với MVP. Những lợi ích chính là cách điều khiển giao diện người dùng đơn giản hơn (ViewModel hoặc Presenter sẽ quan tâm đến nhiệm vụ đó thay vì Model phải kích hoạt các sự kiện cho View sau khi nó được điều khiển bởi Controller).
Hai bài viết hay nhất tôi đã đi qua đó đã giúp tôi hiểu được nguyên tắc là MVC vs MVP vs MVVM và MVVM for Tarded Folks Like Me or MVVM and What it Means to Me
Cảm ơn các liên kết. –
Cảm ơn các liên kết. Tôi hơi bối rối bởi MVP, MVC và MVVM mẫu và nơi để sử dụng chúng. – gyurisc
Tôi nghĩ lợi ích khác là đường cong học tập. Vì hầu hết các nhà phát triển trong các công nghệ giao diện đã sử dụng kiểu mã hóa MVVM, nên dễ dàng hơn để họ chấp nhận giống với mô hình bộ điều khiển nơi họ cần truyền mọi yêu cầu từ xem sang bộ điều khiển và giao tiếp với Mô hình.
tách Components
Trong MVC, bạn có một mối quan hệ tam giác giữa các thành phần. Đó là: Bộ điều khiển sở hữu View và Model. Chế độ xem dựa trên định nghĩa của Mô hình. Mô hình cần đáp ứng các yêu cầu của Chế độ xem.Hãy suy nghĩ về một trung tâm (bộ điều khiển) và kiến trúc đã nói (xem và mô hình)
Trong MVVM, hãy nghĩ rằng hình tam giác đó phẳng ra với mỗi thành phần chỉ biết về một thành phần khác trong chuỗi. Đó là: View-> ViewModel-> Model
Mô hình không biết gì về chồng. ViewModel chỉ biết Mô hình Chế độ xem chỉ biết về Mô hình Xem - không biết Mô hình.
Tại sao điều này quan trọng?
Đây là cốt lõi của câu hỏi gốc.
Mục đích chính là trừu tượng hơn nữa về kiến trúc của bạn. Điều này thường sẽ dẫn đến mã nhiều hơn một chút, nhưng ít điểm liên lạc hơn giữa các đối tượng. Ít điểm tiếp xúc hơn là quan trọng vì điều này dẫn đến mã nhanh hơn. Lớp A/liên hệ nhiều hơn với Lớp A, tác động nhiều hơn đến sự thay đổi trong Hạng A sẽ có. Giảm tác động của thay đổi là một trong những lợi ích chính của kiến trúc tốt.
Để hiểu đầy đủ điều này, bạn nên suy nghĩ về những gì các thành phần thực sự đại diện. Một View, một Controller, một ViewModel, hoặc một Model là gì? Chúng có phải là các định nghĩa theo nghĩa đen hay nhiều khái niệm trừu tượng hơn không?
Theo kinh nghiệm của tôi, việc xem Mô hình là một nhóm các lớp/đối tượng xử lý việc xây dựng và kiên trì dữ liệu. Nó không chỉ là một vật thể đơn giản với các đặc tính. Đó là một lớp thực hiện tìm nạp dữ liệu, lưu dữ liệu, một nhà máy xây dựng các đối tượng thuần cũ. Đó là một lớp mặt tiền cung cấp một API rõ ràng vào dữ liệu. Lớp mặt tiền này có nên được tham chiếu trực tiếp từ Chế độ xem không?
Theo tôi, không nên. Trong MVC, câu trả lời đó cũng là "không". Trình điều khiển tìm nạp dữ liệu từ Mô hình. Về vấn đề đó, MVC và MVVM đạt được cùng một mục tiêu. Trường hợp hai kiến trúc khác nhau là cách dữ liệu và khung nhìn được liên kết.
Giống như Mô hình, Chế độ xem có thể là tập hợp các lớp phối hợp với nhau, hiển thị chế độ xem bản trình bày. Điều này có thể bao gồm một View Controller + View trong trường hợp nền tảng di động (Xem Controller trên iOS, Activity trên Android). Trong nhiều trường hợp, bạn cần một lớp để tải tài liệu dạng xem vào bộ nhớ và cập nhật thuộc tính chế độ xem. Có rất nhiều việc phải làm ở đây. Trong MVC, Bộ điều khiển nhanh chóng trở thành lớp 'bồn rửa nhà bếp' - một loại cơ sở bán phá giá cho bất kỳ điều gì liên quan đến bối cảnh người dùng hiện tại.
Khi bạn nhân điều này qua hàng chục lượt xem tiềm năng trong ứng dụng của mình, bạn kết thúc với nhiều phụ thuộc sâu sắc giữa mã Mô hình mặt sau và mã Chế độ xem trước của bạn. Với các lớp điều khiển lớn, những phụ thuộc này không rõ ràng ngay lập tức.
cầu dẹt ra phụ thuộc của bạn
MVVM flattens ra sự phụ thuộc. Điều này tạo ra sự tập trung. Trọng tâm là gì? Khả năng làm việc trên một phần chức năng duy nhất mà không làm mất tập trung của tất cả các phụ thuộc khác. Bây giờ bạn có thể bắt đầu viết các bài kiểm tra đơn vị trên mã mà trước đây được cho là không thể kiểm chứng được.
Mô hình xem hoạt động như mặt tiền giữa Chế độ xem và Mô hình. Mô hình Xem đáp ứng nhu cầu của Chế độ xem - về mặt kỹ thuật Chế độ xem nên sở hữu Mô hình Xem. Nếu Chế độ xem yêu cầu dữ liệu từ nhiều nguồn, Mô hình xem sẽ đóng gói thành phần của các nguồn dữ liệu riêng biệt thành một đối tượng duy nhất, thống nhất, không chuẩn hóa.Nếu chế độ xem cần gọi lại vào Mô hình hoặc các đích khác, thì Mô hình Xem cung cấp móc và định tuyến cuộc gọi thích hợp.
Xem xét cách hoạt động của bảng vá mạng. Thoạt nhìn, điều này có vẻ dư thừa - tại sao không chỉ đơn giản là dây ethernet của bạn từ điểm A đến điểm B. Nhưng với kinh nghiệm, bạn sẽ hiểu rằng một bảng vá cung cấp cho bạn một phần trừu tượng chính cho phép bạn thay đổi các tuyến của Điểm B không ảnh hưởng đến Điểm A. Đây là những gì mà Mô hình Xem của bạn đang thực hiện.
Bây giờ bạn có một sự trừu tượng rõ ràng giữa Chế độ xem và Mô hình của bạn, hậu quả là Chế độ xem/Bộ điều khiển của bạn chỉ liên quan đến bản trình bày. Điều này có nghĩa là không nên xử lý nội địa hóa hoặc định dạng - nó nhận dữ liệu và trình bày dữ liệu. Mô hình Xem của bạn là một nơi lý tưởng để đặt các loại dữ liệu xem trước này trước đây. Giả sử bạn cần lọc dữ liệu dựa trên tiêu chí. Một lần nữa, View Model là kiến thức về dữ liệu Model (View của bạn không phải là) và là một nơi tuyệt vời để đặt loại mã này.
Khi bạn bắt đầu tổ chức các yêu cầu ứng dụng theo cách này, mã View/Controller của bạn trở nên rõ ràng hơn và khi cần thay đổi, các tác động sẽ rõ ràng hơn, dẫn đến ít lỗi hơn.
Testability
Một lưu ý cuối cùng về testability: Bằng cách làm phẳng ra phụ thuộc, nó làm cho nó dễ dàng hơn để bơm phụ thuộc vào mô hình thử nghiệm của bạn. Nó làm cho thử nghiệm dễ dàng hơn và súc tích hơn. Mô hình Xem của bạn trở thành thứ gì đó mà bạn có thể xác định các trường hợp kiểm tra rõ ràng.
Điều này có thể giúp: http://stackoverflow.com/questions/667781/what-is-the-difference-between-mvc-and-mvvm – SeanJA