Sự khác biệt giữa MVC và MVVM là gì? [đóng cửa]

Có sự khác biệt giữa mẫu "Trình điều khiển Chế độ xem Mô hình" tiêu chuẩn và mẫu Mô hình / Chế độ xem / ViewModel của Microsoft không?

MVC / MVVM không phải là một hoặc / hoặc sự lựa chọn.

Hai mô hình này mọc lên, theo những cách khác nhau, trong cả sự phát triển của ASP.Net và Silverlight / WPF.

Đối với ASP.Net, MVVM được sử dụng để liên kết dữ liệu hai chiều trong các khung nhìn. Đây thường là triển khai phía máy khách (ví dụ: sử dụng Knockout.js). Mặt khác, MVC là một cách để phân tách các mối quan tâm về phía máy chủ .

Cho Silverlight và WPF, mô hình MVVM được bao quát hơn và có thể xuất hiện để hoạt động như một sự thay thế cho MVC (hoặc các mẫu khác của tổ chức phần mềm thành trách nhiệm riêng biệt). Một giả thuyết, rằng thường xuyên xuất hiện của mô hình này khả năng là việc ViewModelchỉ đơn giản là thay thế bộ điều khiển trong MVC(như nếu bạn chỉ có thể thay thế VMcho Ctrong từ viết tắt và tất cả sẽ được tha thứ) ...

ViewModel không nhất thiết phải thay thế nhu cầu về Bộ điều khiển riêng.

Vấn đề là: để có thể kiểm tra độc lập * và đặc biệt có thể sử dụng lại khi cần, mô hình chế độ xem không biết chế độ xem nào đang hiển thị nó, nhưng quan trọng hơn là không biết dữ liệu của nó đến từ đâu .

* Lưu ý: trong thực tế Bộ điều khiển loại bỏ hầu hết logic, khỏi ViewModel, yêu cầu kiểm tra đơn vị. VM sau đó trở thành một thùng chứa câm cần ít thử nghiệm, nếu có ,. Đây là một điều tốt vì VM chỉ là một cầu nối, giữa người thiết kế và người viết mã, vì vậy nên được giữ đơn giản.

Ngay cả trong MVVM, các bộ điều khiển thường sẽ chứa tất cả logic xử lý và quyết định dữ liệu nào sẽ hiển thị trong chế độ xem sử dụng mô hình khung nhìn nào.

Từ những gì chúng ta đã thấy cho đến nay, lợi ích chính của mẫu ViewModel là loại bỏ mã khỏi mã XAML phía sau để giúp XAML chỉnh sửa một tác vụ độc lập hơn . Chúng tôi vẫn tạo các bộ điều khiển, khi và khi cần, để kiểm soát (không có ý định chơi chữ) logic tổng thể của các ứng dụng của chúng tôi.

Các hướng dẫn cơ bản về MVCVM mà chúng tôi tuân theo là:

• Lượt xem hiển thị một hình dạng nhất định của dữ liệu . Họ không biết dữ liệu đến từ đâu.
• ViewModels giữ một hình dạng nhất định của dữ liệu và lệnh , họ không biết dữ liệu hoặc mã đến từ đâu hoặc được hiển thị như thế nào.
• Các mô hình giữ dữ liệu thực tế (bối cảnh khác nhau, lưu trữ hoặc các phương pháp khác)
• Kiểm soát viên lắng nghe và xuất bản các sự kiện. Bộ điều khiển cung cấp logic điều khiển dữ liệu nào được nhìn thấy và ở đâu. Bộ điều khiển cung cấp mã lệnh cho ViewModel để ViewModel thực sự có thể tái sử dụng.

Chúng tôi cũng lưu ý rằng khung công tác mã-điêu khắc triển khai MVVM và một mẫu tương tự như Prism VÀ nó cũng sử dụng rộng rãi các bộ điều khiển để phân tách tất cả logic trường hợp sử dụng.

Đừng cho rằng các bộ điều khiển bị lỗi thời bởi các mô hình View.

Tôi đã bắt đầu một blog về chủ đề này mà tôi sẽ thêm vào và khi nào tôi có thể . Có vấn đề với việc kết hợp MVCVM với các hệ thống điều hướng phổ biến, vì hầu hết các hệ thống điều hướng chỉ sử dụng Chế độ xem và VM, nhưng tôi sẽ đi sâu vào vấn đề đó trong các bài viết sau.

Một lợi ích bổ sung của việc sử dụng mô hình MVCVM là chỉ các đối tượng điều khiển cần tồn tại trong bộ nhớ cho vòng đời của ứng dụng và các bộ điều khiển chứa chủ yếu mã và dữ liệu trạng thái nhỏ (ví dụ như chi phí bộ nhớ nhỏ). Điều này làm cho các ứng dụng chiếm ít bộ nhớ hơn nhiều so với các giải pháp mà các mô hình xem phải được giữ lại và lý tưởng cho một số loại phát triển di động nhất định (ví dụ: Windows Mobile sử dụng Silverlight / Prism / MEF). Tất nhiên điều này phụ thuộc vào loại ứng dụng vì bạn vẫn có thể cần phải giữ lại các máy ảo được lưu trong bộ nhớ cache để đáp ứng.

Lưu ý: Bài đăng này đã được chỉnh sửa nhiều lần và không nhắm mục tiêu cụ thể vào câu hỏi hẹp, vì vậy tôi đã cập nhật phần đầu tiên để bây giờ cũng bao gồm điều đó. Phần lớn các cuộc thảo luận, trong các bình luận bên dưới, chỉ liên quan đến ASP.Net chứ không liên quan đến bức tranh rộng lớn hơn. Bài đăng này nhằm mục đích sử dụng MVVM rộng rãi hơn trong Silverlight, WPF và ASP.Net và cố gắng không khuyến khích mọi người thay thế bộ điều khiển bằng ViewModels.

Tôi nghĩ rằng cách dễ nhất để hiểu những từ viết tắt này có nghĩa là gì để quên chúng trong giây lát. Thay vào đó, hãy nghĩ về phần mềm mà họ có nguồn gốc, mỗi người trong số họ. Nó thực sự nắm bắt được sự khác biệt giữa web đầu tiên và máy tính để bàn.

Khi chúng phát triển phức tạp vào giữa những năm 2000, mẫu thiết kế phần mềm MVC - được mô tả lần đầu tiên vào những năm 1970 - bắt đầu được áp dụng cho các ứng dụng web. Hãy suy nghĩ cơ sở dữ liệu, các trang HTML và mã giữa. Hãy tinh chỉnh điều này chỉ một chút để đến MVC: Đối với »cơ sở dữ liệu«, hãy giả sử cơ sở dữ liệu cộng với mã giao diện. Đối với »trang HTML«, hãy giả sử các mẫu HTML cộng với mã xử lý mẫu. Đối với »mã nằm giữa«, hãy giả sử các lần nhấp ánh xạ mã của người dùng thành hành động, có thể ảnh hưởng đến cơ sở dữ liệu, chắc chắn khiến một chế độ xem khác được hiển thị. Đó là nó, ít nhất là cho mục đích so sánh này.

Chúng ta hãy giữ lại một tính năng của công cụ web này, không phải như ngày nay, mà như nó đã tồn tại mười năm trước, khi JavaScript là một sự phiền toái thấp hèn, đáng khinh bỉ, mà các lập trình viên thực sự đã làm tốt để tránh xa: Trang HTML về cơ bản là ngu ngốc và thụ động . Trình duyệt là một máy khách mỏng, hoặc nếu bạn muốn, một khách hàng kém. Không có trí thông minh trong trình duyệt. Toàn trang tải lại quy tắc. »Chế độ xem« được tạo lại một lần nữa mỗi lần.

Chúng ta hãy nhớ rằng cách thức web này, mặc dù là tất cả các cơn thịnh nộ, đã lạc hậu khủng khiếp so với máy tính để bàn. Ứng dụng máy tính để bàn là khách hàng béo, hoặc khách hàng giàu, nếu bạn muốn. (Ngay cả một chương trình như Microsoft Word cũng có thể được coi là một loại khách hàng, một khách hàng cho các tài liệu.) Họ là những khách hàng đầy thông minh, đầy hiểu biết về dữ liệu của họ. Họ là nhà nước. Họ lưu trữ dữ liệu họ đang xử lý trong bộ nhớ. Không có crap như một trang tải lại đầy đủ.

Và cách thức máy tính để bàn phong phú này có lẽ là nơi viết tắt của từ viết tắt thứ hai, MVVM. Đừng để bị lừa bởi các chữ cái, bởi sự thiếu sót của C. Bộ điều khiển vẫn còn đó. Họ cần phải như vậy. Không có gì được gỡ bỏ. Chúng tôi chỉ cần thêm một điều: trạng thái, dữ liệu được lưu trữ trên máy khách (và cùng với đó là trí thông minh để xử lý dữ liệu đó). Dữ liệu đó, về cơ bản là bộ đệm trên máy khách, giờ được gọi là »ViewModel«. Đó là những gì cho phép tương tác phong phú. Và đó là nó.

• MVC = model, bộ điều khiển, view = về cơ bản là giao tiếp một chiều = khả năng tương tác kém
• MVVM = model, bộ điều khiển, bộ đệm, view = giao tiếp hai chiều = tương tác phong phú

Chúng ta có thể thấy rằng với Flash, Silverlight và - quan trọng nhất - JavaScript, web đã chấp nhận MVVM. Trình duyệt không còn có thể được gọi là khách hàng mỏng một cách hợp pháp. Nhìn vào khả năng lập trình của họ. Nhìn vào mức tiêu thụ bộ nhớ của họ. Nhìn vào tất cả các tương tác Javascript trên các trang web hiện đại.

Cá nhân, tôi thấy lý thuyết và kinh doanh từ viết tắt này dễ hiểu hơn bằng cách nhìn vào những gì nó đề cập đến trong thực tế cụ thể. Các khái niệm trừu tượng là hữu ích, đặc biệt là khi được chứng minh về vấn đề cụ thể, vì vậy sự hiểu biết có thể trở thành vòng tròn đầy đủ.

ViewModel MVVM Model-View tương tự như MVC, Model-View Controller

Bộ điều khiển được thay thế bằng ViewModel . ViewModel nằm bên dưới lớp UI. ViewModel hiển thị các đối tượng dữ liệu và lệnh mà khung nhìn cần. Bạn có thể nghĩ về điều này như một đối tượng chứa mà khung nhìn sẽ lấy dữ liệu và hành động của nó. ViewModel lấy dữ liệu từ mô hình.

Russel East có một blog thảo luận chi tiết hơn Tại sao MVVM khác với MVC

Đối với một điều, MVVM là một sự tiến triển của mẫu MVC sử dụng XAML để xử lý hiển thị. Bài viết này phác thảo một số khía cạnh của hai.

Lực đẩy chính của kiến ​​trúc Model / View / ViewModel dường như nằm ở phía trên dữ liệu (Vượt mô hình), có một lớp khác của các thành phần không trực quan (Hồi giáo ViewModel,) ánh xạ các khái niệm của dữ liệu chặt chẽ hơn theo các khái niệm về chế độ xem dữ liệu (Giới thiệu về Xem). Đó là ViewModel mà View liên kết trực tiếp, không phải Model trực tiếp.

Microsoft đã cung cấp một lời giải thích về Mẫu MVVM trong môi trường Windows tại đây .

Đây là một phần quan trọng:

Trong mẫu thiết kế Model-View-ViewModel, một ứng dụng bao gồm ba thành phần chung.

• Model : Điều này thể hiện mô hình dữ liệu mà ứng dụng của bạn tiêu thụ. Ví dụ: trong ứng dụng chia sẻ hình ảnh, lớp này có thể đại diện cho bộ ảnh có sẵn trên thiết bị và API được sử dụng để đọc và ghi vào thư viện ảnh.

• Xem : Một ứng dụng thường bao gồm nhiều trang UI. Mỗi trang hiển thị cho người dùng là một khung nhìn theo thuật ngữ MVVM. Khung nhìn là mã XAML được sử dụng để xác định và định kiểu những gì người dùng nhìn thấy. Dữ liệu từ mô hình được hiển thị cho người dùng và đó là công việc của ViewModel để cung cấp cho UI dữ liệu này dựa trên trạng thái hiện tại của ứng dụng. Ví dụ: trong ứng dụng chia sẻ hình ảnh, các chế độ xem sẽ là giao diện người dùng hiển thị cho người dùng danh sách các album trên thiết bị, các hình ảnh trong album và có lẽ một chế độ khác hiển thị cho người dùng một hình ảnh cụ thể.

• ViewModel : ViewModel liên kết mô hình dữ liệu, hoặc đơn giản là mô hình, với UI hoặc các khung nhìn của ứng dụng. Nó chứa logic để quản lý dữ liệu từ mô hình và hiển thị dữ liệu dưới dạng một tập các thuộc tính mà UI XAML hoặc các khung nhìn có thể liên kết. Ví dụ: trong một ứng dụng chia sẻ hình ảnh, ViewModel sẽ hiển thị danh sách các album và cho mỗi album sẽ hiển thị một danh sách các hình ảnh. Giao diện người dùng không rõ nguồn gốc của hình ảnh và cách chúng được lấy. Nó chỉ đơn giản biết một tập hợp các hình ảnh được hiển thị bởi ViewModel và hiển thị chúng cho người dùng.

Tôi nghĩ một trong những khác biệt chính là trong MVC, V của bạn đọc M trực tiếp và thông qua C để thao tác dữ liệu, trong khi trong MVVM, VM của bạn hoạt động như một proxy M, cũng như cung cấp chức năng có sẵn cho bạn V.

Nếu tôi không đầy rác, tôi ngạc nhiên không ai tạo ra một hybrid, trong đó VM của bạn chỉ là một proxy M và C cung cấp tất cả các chức năng.

MVC là một môi trường được kiểm soát và MVVM là một môi trường phản ứng.

Trong một môi trường được kiểm soát, bạn nên có ít mã hơn và một nguồn logic chung; mà phải luôn luôn sống trong bộ điều khiển. Tuy nhiên; Trong thế giới web, MVC dễ dàng được chia thành logic tạo khung nhìn và xem logic động. Sáng tạo sống trên máy chủ và sống động trên máy khách. Bạn thấy điều này rất nhiều với ASP.NET MVC kết hợp với AngularJS trong khi máy chủ sẽ tạo View và truyền trong Model và gửi nó cho máy khách. Sau đó, khách hàng sẽ tương tác với Chế độ xem trong trường hợp AngularJS bước vào như một bộ điều khiển cục bộ. Sau khi gửi Mô hình hoặc Mô hình mới được gửi lại cho bộ điều khiển máy chủ và được xử lý. (Do đó, chu trình tiếp tục và có rất nhiều bản dịch khác về cách xử lý này khi làm việc với các socket hoặc AJAX, v.v. nhưng trên tất cả các kiến ​​trúc là giống hệt nhau.)

MVVM là một môi trường phản ứng có nghĩa là bạn thường viết mã (như trình kích hoạt) sẽ kích hoạt dựa trên một số sự kiện. Trong XAML, nơi MVVM phát triển mạnh, tất cả đều được thực hiện dễ dàng với khung dữ liệu được tích hợp sẵn NHƯNG như đã đề cập, nó sẽ hoạt động trên mọi hệ thống trong mọi Chế độ xem với bất kỳ ngôn ngữ lập trình nào. Nó không phải là MS cụ thể. ViewModel kích hoạt (thường là một sự kiện thay đổi thuộc tính) và View phản ứng với nó dựa trên bất kỳ kích hoạt nào bạn tạo. Điều này có thể có được kỹ thuật nhưng điểm mấu chốt là Chế độ xem không trạng thái và không có logic. Nó chỉ đơn giản là thay đổi trạng thái dựa trên các giá trị. Hơn nữa, ViewModels không trạng thái với rất ít logic và Mô hình là Trạng thái có logic cơ bản là Zero vì chúng chỉ nên duy trì trạng thái. Tôi mô tả đây là trạng thái ứng dụng (Model), trình dịch trạng thái (ViewModel), và sau đó là trạng thái / tương tác trực quan (View).

Trong máy tính để bàn hoặc ứng dụng phía máy khách MVC, bạn nên có Model và Model nên được sử dụng bởi Bộ điều khiển. Dựa trên Model, bộ điều khiển sẽ sửa đổi View. Chế độ xem thường được gắn với Bộ điều khiển với Giao diện để Bộ điều khiển có thể hoạt động với nhiều Chế độ xem khác nhau. Trong ASP.NET, logic cho MVC hơi ngược trên máy chủ khi Trình điều khiển quản lý các Mô hình và chuyển các Mô hình sang Chế độ xem được chọn. Chế độ xem sau đó chứa đầy dữ liệu dựa trên mô hình và có logic riêng (thường là một bộ MVC khác như được thực hiện với AngularJS). Mọi người sẽ tranh luận và hiểu điều này với ứng dụng MVC và cố gắng thực hiện cả hai điểm mà việc duy trì dự án cuối cùng sẽ trở thành một thảm họa. LUÔN LUÔN đặt logic và điều khiển ở một vị trí khi sử dụng MVC. KHÔNG viết Logic xem trong mã phía sau Chế độ xem (hoặc trong Chế độ xem qua JS cho web) để chứa dữ liệu Bộ điều khiển hoặc Mô hình. Hãy để Bộ điều khiển thay đổi Chế độ xem. Logic CHỈ tồn tại trong Chế độ xem là bất cứ điều gì cần thiết để tạo và chạy qua Giao diện mà nó đang sử dụng. Một ví dụ về điều này là gửi tên người dùng và mật khẩu. Cho dù máy tính để bàn hay trang web (trên máy khách), Bộ điều khiển sẽ xử lý quá trình gửi bất cứ khi nào Chế độ xem kích hoạt hành động Gửi. Nếu được thực hiện chính xác, bạn luôn có thể dễ dàng tìm đường đi trên một trang web MVC hoặc ứng dụng cục bộ. Cho dù máy tính để bàn hay trang web (trên máy khách), Bộ điều khiển sẽ xử lý quá trình gửi bất cứ khi nào Chế độ xem kích hoạt hành động Gửi. Nếu được thực hiện chính xác, bạn luôn có thể dễ dàng tìm đường đi trên một trang web MVC hoặc ứng dụng cục bộ. Cho dù máy tính để bàn hay trang web (trên máy khách), Bộ điều khiển sẽ xử lý quá trình gửi bất cứ khi nào Chế độ xem kích hoạt hành động Gửi. Nếu được thực hiện chính xác, bạn luôn có thể dễ dàng tìm đường đi trên một trang web MVC hoặc ứng dụng cục bộ.

MVVM là sở thích cá nhân của tôi vì nó hoàn toàn phản ứng. Nếu Mô hình thay đổi trạng thái, ViewModel lắng nghe và dịch trạng thái đó và đó là trạng thái đó !!! Sau đó, View đang lắng nghe ViewModel để thay đổi trạng thái và nó cũng cập nhật dựa trên bản dịch từ ViewModel. Một số người gọi nó là MVVM thuần túy nhưng thực sự chỉ có một và tôi không quan tâm đến cách bạn tranh luận về nó và đó luôn là MVVM thuần túy trong đó Chế độ xem hoàn toàn không có logic.

Đây là một ví dụ nhỏ: giả sử bạn muốn có một menu trượt trong một nút nhấn. Trong MVC, bạn sẽ có một hành động MenuPress trong giao diện của mình. Bộ điều khiển sẽ biết khi bạn nhấp vào nút Menu và sau đó báo cho View để trượt trong Menu dựa trên một phương thức Giao diện khác, chẳng hạn như SlideMothyIn. Một chuyến đi khứ hồi vì lý do gì? Việc điều khiển quyết định bạn không thể hoặc muốn làm điều gì khác thay vì đó là lý do. Bộ điều khiển phải chịu trách nhiệm về Chế độ xem với Chế độ xem không làm gì trừ khi Bộ điều khiển nói như vậy. TUY NHIÊN; trong MVVM, trình đơn slide trong hoạt hình nên được xây dựng và chung chung và thay vì được yêu cầu trượt nó vào sẽ làm như vậy dựa trên một số giá trị. Vì vậy, nó lắng nghe ViewModel và khi ViewModel nói, IsMothyActive = true (hoặc tuy nhiên) hoạt hình cho điều đó diễn ra. Hiện nay, với điều đó nói rằng tôi muốn làm cho một điểm khác THỰC SỰ R CLE RÀNG và xin vui lòng chú ý. IsMothyActive có lẽ là thiết kế BAD MVVM hoặc ViewModel. Khi thiết kế ViewModel, bạn không bao giờ nên cho rằng View sẽ có bất kỳ tính năng nào và chỉ cần chuyển trạng thái mô hình đã dịch. Theo cách đó, nếu bạn quyết định thay đổi Chế độ xem của mình để xóa Menu và chỉ hiển thị dữ liệu / tùy chọn theo cách khác, ViewModel không quan tâm. Vậy bạn sẽ quản lý Menu như thế nào? Khi dữ liệu có ý nghĩa như thế nào. Vì vậy, một cách để làm điều này là cung cấp cho Menu một danh sách các tùy chọn (có thể là một mảng của ViewModels bên trong). Nếu danh sách đó có dữ liệu, Menu sẽ biết mở thông qua kích hoạt, nếu không thì nó sẽ biết ẩn thông qua kích hoạt. Bạn chỉ cần có dữ liệu cho menu hoặc không có trong ViewModel. KHÔNG quyết định hiển thị / ẩn dữ liệu đó trong ViewModel .. chỉ cần dịch trạng thái của Mô hình. Bằng cách này, View hoàn toàn phản ứng và chung chung và có thể được sử dụng trong nhiều tình huống khác nhau.

Tất cả những điều này có lẽ hoàn toàn vô nghĩa nếu bạn chưa từng quen thuộc với kiến ​​trúc của mỗi thứ và việc học có thể rất khó hiểu khi bạn tìm thấy thông tin ALOT OF BAD trên mạng.

Vì vậy, ... những điều cần lưu ý để có được điều này đúng. Quyết định trước cách thiết kế ứng dụng của bạn và DỄ DÀNG NÓ.

Nếu bạn làm MVC, điều này thật tuyệt, thì hãy đảm bảo Bộ điều khiển của bạn có thể quản lý được và kiểm soát hoàn toàn Chế độ xem của bạn. Nếu bạn có Chế độ xem lớn, hãy cân nhắc thêm các điều khiển vào Chế độ xem có các Bộ điều khiển khác nhau. CHỈ KHÔNG xếp tầng các bộ điều khiển này vào các bộ điều khiển khác nhau. Rất bực bội để duy trì. Dành một chút thời gian và thiết kế mọi thứ riêng biệt theo cách sẽ hoạt động như các thành phần riêng biệt ... Và luôn để Bộ điều khiển nói với Model để cam kết hoặc duy trì lưu trữ. Thiết lập phụ thuộc lý tưởng cho MVC trong là View ← Trình điều khiển → Mô hình hoặc với ASP.NET (không giúp tôi bắt đầu) Model ← Xem ↔ Trình điều khiển → Mô hình (trong đó Mô hình có thể giống hoặc một Mô hình hoàn toàn khác từ Trình điều khiển đến Chế độ xem)... tất nhiên chỉ cần biết về Bộ điều khiển trong Chế độ xem tại thời điểm này chủ yếu là để tham chiếu điểm cuối để biết nơi quay lại để vượt qua Mô hình.

Nếu bạn làm MVVM, tôi chúc phúc cho linh hồn tốt bụng của bạn, nhưng hãy dành thời gian để làm điều đó ĐÚNG! Không sử dụng giao diện cho một. Hãy để Chế độ xem của bạn quyết định cách nhìn sẽ dựa trên các giá trị. Chơi với View với dữ liệu Mock. Nếu cuối cùng bạn có Chế độ xem hiển thị cho bạn một Menu (theo ví dụ) mặc dù lúc đó bạn không muốn nó thì TỐT. Chế độ xem của bạn đang hoạt động như bình thường và phản ứng dựa trên các giá trị như bình thường. Chỉ cần thêm một vài yêu cầu nữa vào trình kích hoạt của bạn để đảm bảo điều này không xảy ra khi ViewModel ở trạng thái được dịch cụ thể hoặc ra lệnh cho ViewModel để làm trống trạng thái này. Trong ViewModel của bạn KHÔNG loại bỏ điều này bằng logic bên trong như thể bạn quyết định từ đó xem liệu Chế độ xem có nhìn thấy hay không. Hãy nhớ rằng bạn không thể cho rằng có menu hay không trong ViewModel. Và cuối cùng, Mô hình chỉ cho phép bạn thay đổi và rất có thể là trạng thái lưu trữ. Đây là nơi xác nhận và tất cả sẽ xảy ra; ví dụ: nếu Model không thể sửa đổi trạng thái thì nó sẽ tự gắn cờ là bẩn hoặc một cái gì đó. Khi ViewModel nhận ra điều này, nó sẽ dịch những gì bẩn và View sẽ nhận ra điều này và hiển thị một số thông tin thông qua một trình kích hoạt khác. Tất cả dữ liệu trong Chế độ xem có thể được liên kết với ViewModel để mọi thứ chỉ có thể động mà Model và ViewModel hoàn toàn không biết về cách View sẽ phản ứng với liên kết. Vì thực tế, Model cũng không có ý tưởng về ViewModel. Khi thiết lập các phụ thuộc, họ nên chỉ như vậy và chỉ như vậy T sửa đổi trạng thái sau đó nó sẽ đơn giản tự gắn cờ là bẩn hoặc một cái gì đó. Khi ViewModel nhận ra điều này, nó sẽ dịch những gì bẩn và View sẽ nhận ra điều này và hiển thị một số thông tin thông qua một trình kích hoạt khác. Tất cả dữ liệu trong Chế độ xem có thể được liên kết với ViewModel để mọi thứ chỉ có thể động mà Model và ViewModel hoàn toàn không biết về cách View sẽ phản ứng với liên kết. Vì thực tế, Model cũng không có ý tưởng về ViewModel. Khi thiết lập các phụ thuộc, họ nên chỉ như vậy và chỉ như vậy T sửa đổi trạng thái sau đó nó sẽ đơn giản tự gắn cờ là bẩn hoặc một cái gì đó. Khi ViewModel nhận ra điều này, nó sẽ dịch những gì bẩn và View sẽ nhận ra điều này và hiển thị một số thông tin thông qua một trình kích hoạt khác. Tất cả dữ liệu trong Chế độ xem có thể được liên kết với ViewModel để mọi thứ chỉ có thể động mà Model và ViewModel hoàn toàn không biết về cách View sẽ phản ứng với liên kết. Vì thực tế, Model cũng không có ý tưởng về ViewModel. Khi thiết lập các phụ thuộc, họ nên chỉ như vậy và chỉ như vậy Tất cả dữ liệu trong Chế độ xem có thể được liên kết với ViewModel để mọi thứ chỉ có thể động mà Model và ViewModel hoàn toàn không biết về cách View sẽ phản ứng với liên kết. Vì thực tế, Model cũng không có ý tưởng về ViewModel. Khi thiết lập các phụ thuộc, họ nên chỉ như vậy và chỉ như vậy Tất cả dữ liệu trong Chế độ xem có thể được liên kết với ViewModel để mọi thứ chỉ có thể động mà Model và ViewModel hoàn toàn không biết về cách View sẽ phản ứng với liên kết. Vì thực tế, Model cũng không có ý tưởng về ViewModel. Khi thiết lập các phụ thuộc, họ nên chỉ như vậy và chỉ như vậyXem → ViewModel → Mô hình (và một ghi chú bên cạnh ở đây ... và điều này có thể cũng sẽ bị tranh cãi nhưng tôi không quan tâm ... ĐỪNG BỎ L MOD MÔ HÌNH cho XEM, trừ khi MODEL đó là bất biến, nếu không thì bọc nó bằng một ViewModel thích hợp. Chế độ xem không nên xem giai đoạn mô hình. Tôi đưa ra một con chuột bẻ khóa bản demo bạn đã xem hoặc cách bạn thực hiện nó, điều đó sai.)

Đây là mẹo cuối cùng của tôi ... Hãy nhìn vào một ứng dụng MVC được thiết kế tốt nhưng rất đơn giản và làm tương tự cho một ứng dụng MVVM. Một người sẽ có nhiều quyền kiểm soát hơn với giới hạn không linh hoạt trong khi người kia sẽ không có quyền kiểm soát và tính linh hoạt không giới hạn.

Một môi trường được kiểm soát là tốt để quản lý toàn bộ ứng dụng từ một bộ điều khiển hoặc (một nguồn duy nhất) trong khi môi trường phản ứng có thể được chia thành các kho riêng biệt mà hoàn toàn không biết phần còn lại của ứng dụng đang làm gì. Quản lý vi mô vs quản lý miễn phí.

Nếu tôi không nhầm lẫn bạn, hãy thử liên hệ với tôi ... Tôi không bận tâm đến vấn đề này một cách chi tiết với hình minh họa và ví dụ.

Vào cuối ngày, tất cả chúng ta đều là những lập trình viên và với tình trạng hỗn loạn đó tồn tại trong chúng ta khi viết mã ... Vì vậy, các quy tắc sẽ bị phá vỡ, các lý thuyết sẽ thay đổi, và tất cả những điều này sẽ kết thúc ... các dự án và trên các nhóm lớn, nó thực sự giúp thống nhất về một mẫu thiết kế và thực thi nó. Một ngày nào đó nó sẽ làm cho các bước nhỏ thêm được thực hiện ngay từ đầu trở thành bước nhảy vọt về tiết kiệm sau này.

Sự khác biệt đơn giản: (Lấy cảm hứng từ khóa học Coursera AngularJS của Yaakov)

MVC (Model View Controller)

1. Mô hình: Mô hình chứa thông tin dữ liệu. Không gọi hoặc sử dụng Trình điều khiển và Chế độ xem. Chứa logic kinh doanh và cách thể hiện dữ liệu. Một số dữ liệu này, trong một số hình thức, có thể được hiển thị trong chế độ xem. Nó cũng có thể chứa logic để lấy dữ liệu từ một số nguồn.
2. Trình điều khiển: Hoạt động như kết nối giữa chế độ xem và mô hình. Xem cuộc gọi Bộ điều khiển và Bộ điều khiển gọi mô hình. Về cơ bản, nó thông báo cho mô hình và / hoặc khung nhìn để thay đổi khi thích hợp.
3. Xem: Thỏa thuận với phần UI. Tương tác với người dùng.

MVVM (Model View View Model)

ViewModel :

1. Nó là đại diện của trạng thái của quan điểm.
2. Nó giữ dữ liệu được hiển thị trong chế độ xem.
3. Trả lời để xem các sự kiện, còn gọi là logic trình bày.
4. Gọi các chức năng khác để xử lý logic kinh doanh.
5. Không bao giờ trực tiếp yêu cầu xem để hiển thị bất cứ điều gì.

MVVM là một sàng lọc (gây tranh cãi) của mẫu Mô hình trình bày . Tôi nói là gây tranh cãi, bởi vì sự khác biệt duy nhất là cách WPF cung cấp khả năng thực hiện ràng buộc dữ liệu và xử lý lệnh.

Viewmodel là một mô hình "trừu tượng" cho các thành phần giao diện người dùng của bạn. Nó phải cho phép bạn thực hiện các lệnh và hành động theo quan điểm của bạn theo cách không trực quan (ví dụ để kiểm tra nó).

Nếu bạn đã làm việc với MVC, đôi khi bạn có thể thấy hữu ích khi tạo các đối tượng mô hình để phản ánh trạng thái của chế độ xem của bạn, ví dụ, để hiển thị và ẩn một số hộp thoại chỉnh sửa, v.v. Trong trường hợp đó bạn đang sử dụng chế độ xem.

Mẫu MVVM chỉ đơn giản là khái quát hóa thực tiễn đó cho tất cả các thành phần UI.

Và đó không phải là một mẫu của Microsoft, điều bổ sung là các ràng buộc dữ liệu WPF / Silverlight đặc biệt phù hợp để làm việc với mẫu này. Nhưng không có gì ngăn bạn sử dụng nó với các mặt máy chủ java chẳng hạn.

Các câu trả lời khác có thể không dễ hiểu đối với một người không quen thuộc nhiều với chủ đề của các mẫu kiến ​​trúc. Một người chưa quen với kiến ​​trúc ứng dụng có thể muốn biết sự lựa chọn của nó có thể ảnh hưởng đến ứng dụng của cô ấy như thế nào trong thực tế và tất cả những gì ồn ào trong cộng đồng.

Cố gắng làm sáng tỏ những điều trên, tôi đã tạo ra kịch bản này liên quan đến MVVM, MVP và MVC. Câu chuyện bắt đầu khi một người dùng nhấp vào nút 'TÌM' trong ứng dụng tìm kiếm phim

Người dùng: Click vào

Xem : Ai vậy? [ MVVM | MVP | MVC ]

Thành viên: Tôi vừa bấm vào nút tìm kiếm

Xem : Ok, chờ một giây. [ MVVM | MVP | MVC ]

( Xem cách gọi ViewModel | Presenter | Bộ điều khiển ...) [ MVVM | MVP | MVC ]

Xem : Hey ViewModel | Người trình bày | Trình điều khiển , một Người dùng vừa nhấp vào nút tìm kiếm, tôi phải làm gì? [ MVVM | MVP | MVC ]

ViewModel | Người trình bày | Trình điều khiển : Hey View , có bất kỳ thuật ngữ tìm kiếm nào trên trang đó không? [ MVVM | MVP | MVC ]

Xem : Có, ở đây là làng piano piano [ MVVM | MVP | MVC ]

Đây là sự khác biệt quan trọng nhất giữa MVVM VÀ MVP | MVC ---

Người dẫn chương trình : Cảm ơn Chế độ xem , khi đó tôi đang tìm kiếm cụm từ tìm kiếm trên Mô hình , vui lòng cho anh ấy / cô ấy xem thanh tiến trình [ MVP | MVC ]

( Người thuyết trình | Trình điều khiển đang gọi Model Model ) [ MVP | MVC ]

ViewContoder : Cảm ơn, tôi sẽ tìm kiếm thuật ngữ tìm kiếm trên Model nhưng sẽ không cập nhật trực tiếp cho bạn. Thay vào đó, tôi sẽ kích hoạt các sự kiện để searchResultsListObservable nếu có bất kỳ kết quả nào. Vì vậy, bạn đã quan sát tốt hơn về điều đó. [ MVVM ]

(Trong khi quan sát bất kỳ trình kích hoạt nào trong searchResultsListObservable, View nghĩ rằng nó sẽ hiển thị một số thanh tiến trình cho người dùng, vì ViewModel sẽ không nói chuyện với nó về điều đó)

Trong khi bạn đang ở

ViewModel | Người trình bày | Điều khiển : Hey mẫu , Bạn có bất cứ trận đấu cụm từ tìm kiếm này ?: “piano” [ MVVM | MVP | MVC ]

Mô hình : Hey ViewModel | Người trình bày | Bộ điều khiển , hãy để tôi kiểm tra [ MVVM | MVP | MVC ]

( Người mẫu đang thực hiện truy vấn cơ sở dữ liệu phim ') [ MVVM | MVP | MVC ]

( Sau một lúc … )

---- Đây là điểm phân kỳ giữa MVVM , MVP và MVC -----

Model : Tôi đã tìm thấy một danh sách cho bạn, ViewModel | Người dẫn chương trình , ở đây nó là trong JSON “[{‘tên’:” Piano Teacher”,” năm”: 2001}, {‘tên’:” Piano”,” năm”: 1993}]” [ MVVM | MVP ]

Mô hình : Có một số kết quả có sẵn, Bộ điều khiển. Tôi đã tạo một biến trường trong ví dụ của mình và điền vào kết quả. Tên của nó là Tìm kiếmResultsList ốp lưng [ MVC ]

( Người thuyết trình | Trình điều khiển cảm ơn Người mẫu và quay lại Chế độ xem ) [ MVP | MVC ]

Người thuyết trình : Cảm ơn vì đã chờ Xem , tôi đã tìm thấy một danh sách các kết quả phù hợp với bạn và sắp xếp chúng theo một định dạng có thể trình bày: [Nhạc Piano Piano 2001, Nhạc Piano 1993 Hồi]. Ngoài ra, vui lòng ẩn thanh tiến trình ngay bây giờ [ MVP ]

Trình điều khiển : Cảm ơn vì đã chờ Xem , tôi đã hỏi Model về truy vấn tìm kiếm của bạn. Nó nói rằng nó đã tìm thấy một danh sách các kết quả phù hợp và lưu trữ chúng trong một biến có tên là Tìm kiếmResultsList tựa trong ví dụ của nó. Bạn có thể lấy nó từ đó. Ngoài ra, vui lòng ẩn thanh tiến trình ngay bây giờ [ MVC ]

ViewModel : Bất kỳ người quan sát nào trên searchResultsListObservable đều được thông báo rằng có danh sách mới này ở định dạng có thể trình bày: [Hồi Piano Piano 2001, Khăn Piano 1993 1993]. [ MVVM ]

Xem : Cảm ơn bạn rất nhiều Người trình bày [ MVP ]

Chế độ xem : Cảm ơn bạn Bộ điều khiển cứng [ MVC ] (Bây giờ Chế độ xem đang tự đặt câu hỏi: Tôi nên trình bày kết quả tôi nhận được từ Mô hình cho người dùng như thế nào? Năm sản xuất của bộ phim sẽ đến trước hay cuối cùng?)

Xem : Ồ, có một trình kích hoạt mới trong searchResultsListObservable, tốt, có một danh sách có thể trình bày, bây giờ tôi chỉ phải hiển thị nó trong một danh sách. Tôi cũng nên ẩn thanh tiến trình bây giờ tôi có kết quả. [ MVVM ]

Trong trường hợp bạn quan tâm, tôi đã viết một loạt bài viết ở đây , so sánh MVVM, MVP và MVC bằng cách triển khai một ứng dụng tìm kiếm phim android.

Tiêm ViewModels được gõ mạnh vào View bằng MVC

1. Bộ điều khiển chịu trách nhiệm làm mới ViewModel và đưa nó vào View. (để nhận yêu cầu)
2. ViewModel là bộ chứa cho DataContext và trạng thái xem, chẳng hạn như mục được chọn cuối cùng, v.v.
3. Mô hình chứa các thực thể DB và rất gần với Lược đồ DB, nó thực hiện các truy vấn và lọc. (Tôi thích EF và LINQ cho việc này)
4. Mô hình cũng nên xem xét các kho lưu trữ và hoặc chiếu kết quả thành các loại mạnh (EF có một phương pháp tuyệt vời ... EF.Database.Select (chuỗi truy vấn, parms) để truy cập ADO trực tiếp vào các truy vấn tiêm và lấy lại các loại mạnh. là đối số chậm. EF không phải là SLOW !
5. ViewModel lấy dữ liệu và thực hiện các quy tắc và xác nhận nghiệp vụ
6. Bộ điều khiển trên bài đăng trở lại sẽ cal phương thức ViewModel Post và chờ kết quả.
7. Bộ điều khiển sẽ đưa Viewmodel mới được cập nhật vào View. Chế độ xem chỉ sử dụng ràng buộc loại mạnh .
8. Khung nhìn chỉ hiển thị dữ liệu và gửi các sự kiện trở lại bộ điều khiển. (xem ví dụ dưới đây)
9. MVC chặn yêu cầu gửi đến và định tuyến nó đến bộ điều khiển thích hợp với kiểu dữ liệu mạnh

Trong mô hình này, không còn liên hệ cấp HTTP với các đối tượng yêu cầu hoặc phản hồi vì máy MVC của MSFT ẩn nó khỏi chúng tôi.

Để làm rõ mục 6 ở trên (theo yêu cầu) ...

Giả sử một ViewModel như thế này:

public class myViewModel{
     public string SelectedValue {get;set;}
public void Post(){
    //due to MVC model binding the SelectedValue string above will be set by MVC model binding on post back.
    //this allows you to do something with it.
    DoSomeThingWith(SelectedValue);
    SelectedValue = "Thanks for update!";
 }
}

Phương thức điều khiển của bài đăng sẽ trông như thế này (Xem bên dưới), lưu ý rằng ví dụ của mvm được tự động cung cấp bởi các cơ chế liên kết MVC. Kết quả là bạn không bao giờ phải thả xuống lớp chuỗi truy vấn! Đây là MVC khởi tạo ViewModel cho bạn dựa trên các chuỗi truy vấn!

[HTTPPOST]   
public ActionResult MyPostBackMethod (myViewModel mvm){
         if (ModelState.IsValid)
        {
               // Immediately call the only method needed in VM...
               mvm.Post()
        }
      return View(mvm);
}

Lưu ý rằng để hành động này ở trên hoạt động như bạn dự định, bạn phải có một CTOR null được xác định rằng nội tâm hóa những thứ không được trả lại trong bài. Bài đăng trở lại cũng phải đăng lại cặp tên / giá trị cho những điều đã thay đổi. Nếu có các cặp tên / giá trị bị thiếu, công cụ liên kết MVC sẽ thực hiện điều phù hợp mà đơn giản là không có gì! Nếu điều này xảy ra, bạn có thể thấy mình nói "Tôi đang mất dữ liệu trên các bài đăng" ...

Ưu điểm của mẫu này là ViewModel thực hiện tất cả các công việc "lộn xộn" liên quan đến logic Model / Buisness, bộ điều khiển chỉ là một bộ định tuyến sắp xếp. Đó là SOC trong hành động.

MVVM thêm mô hình khung nhìn vào hỗn hợp. Điều này rất quan trọng, vì nó cho phép bạn sử dụng rất nhiều cách tiếp cận ràng buộc của WPF, mà không đưa tất cả các phần cụ thể UI đó vào mô hình thông thường của bạn.

Tôi có thể sai, nhưng tôi không chắc MVVM thực sự buộc bộ điều khiển vào hỗn hợp. Tôi thấy khái niệm này phù hợp hơn với: http://martinfowler.com/eaaDev/PftimeationModel.html . Tôi nghĩ rằng mọi người chọn kết hợp nó với MVC, chứ không phải nó được tích hợp vào mẫu.

Từ những gì tôi có thể nói, MVVM ánh xạ tới MV của MVC - có nghĩa là trong mẫu MVC truyền thống, V không giao tiếp trực tiếp với M. Trong phiên bản thứ hai của MVC, có một liên kết trực tiếp giữa M và V. MVVM dường như nhận tất cả các tác vụ liên quan đến giao tiếp M và V và kết hợp nó để tách nó ra khỏi C. Thực tế, vẫn còn quy trình ứng dụng phạm vi lớn hơn (hoặc thực hiện các kịch bản sử dụng) không được tính toán đầy đủ trong MVVM. Đây là vai trò của bộ điều khiển. Bằng cách loại bỏ các khía cạnh cấp thấp hơn khỏi bộ điều khiển, chúng sạch hơn và giúp dễ dàng sửa đổi kịch bản sử dụng và logic nghiệp vụ của ứng dụng, cũng làm cho bộ điều khiển có thể tái sử dụng nhiều hơn.

Tôi ngạc nhiên rằng đây là một câu trả lời được bình chọn cao mà không đề cập đến nguồn gốc của MVVM. MVVM là một thuật ngữ phổ biến được sử dụng trong cộng đồng Microsoft và nó có nguồn gốc từ Mô hình trình bày của Martin Fowler . Vì vậy, để hiểu động cơ của mẫu và sự khác biệt với những người khác, bài viết gốc về mẫu là điều đầu tiên cần đọc.

Chà, nói chung MVC được sử dụng trong phát triển Web và MVVM là phổ biến nhất trong phát triển WPF / Silverlight. Tuy nhiên, đôi khi kiến ​​trúc web có thể có sự pha trộn của MVC và MVVM.

Ví dụ: bạn có thể sử dụng knoutout.js và trong trường hợp này bạn sẽ có MVVM ở phía máy khách của mình. Và phía máy chủ MVC của bạn cũng có thể thay đổi. Trong các ứng dụng phức tạp, không ai sử dụng Model thuần túy. Có thể có ý nghĩa khi sử dụng ViewModel làm "Mô hình" của MVC và Mô hình thực của bạn về cơ bản sẽ là một phần của VM này. Điều này cung cấp cho bạn một lớp trừu tượng thêm.

MVVMC, hoặc có lẽ là MVC +, dường như là một cách tiếp cận khả thi cho doanh nghiệp cũng như phát triển ứng dụng nhanh chóng. Mặc dù thật tuyệt khi tách giao diện người dùng khỏi logic kinh doanh và logic tương tác, mẫu MVVM 'thuần túy' và hầu hết các ví dụ khả dụng nhất hoạt động tốt nhất trên các chế độ xem đơn lẻ.

Tuy nhiên, không chắc chắn về thiết kế của bạn, nhưng hầu hết các ứng dụng của tôi đều chứa các trang và một số chế độ xem (có thể sử dụng lại) và do đó, ViewModels cần phải tương tác ở một mức độ nào đó. Việc sử dụng trang làm trình điều khiển sẽ hoàn toàn đánh bại mục đích của MVVM, do đó, không sử dụng cách tiếp cận "VM-C" cho logic cơ bản có thể dẫn đến .. à .. các cấu trúc đầy thách thức khi ứng dụng đáo hạn. Ngay cả trong VB-6, hầu hết chúng ta có lẽ đã dừng mã hóa logic nghiệp vụ vào sự kiện Nút và bắt đầu các lệnh 'chuyển tiếp' đến bộ điều khiển, phải không? Gần đây tôi đã xem xét nhiều framworks mới nổi về chủ đề đó; yêu thích của tôi rõ ràng là phương pháp Magellan (tại codeplex). Chúc mừng mã hóa!

http://en.wikipedia.org/wiki/Model_View_ViewModel#References

Bộ điều khiển không được thay thế bằng ViewModel trong MVVM, vì ViewModel có chức năng hoàn toàn khác với Bộ điều khiển. Bạn vẫn cần một Trình điều khiển, vì không có Trình điều khiển, Model của bạn, ViewModel và View sẽ không hoạt động nhiều ... Trong MVVM, bạn cũng có Trình điều khiển, tên MVVM chỉ là sai.

MVVMC là tên chính xác theo ý kiến ​​khiêm tốn của tôi.

Như bạn có thể thấy ViewModel chỉ là một bổ sung cho mẫu MVC. Nó di chuyển logic chuyển đổi (ví dụ: chuyển đổi đối tượng thành một chuỗi) từ Bộ điều khiển sang ViewModel.

Tôi đã thực hiện một bài viết Trung bình cho việc này.

MVVM

1. Xem ➡ ViewModel ➡ Model

   • Khung nhìn có tham chiếu đến ViewModel nhưng không phải ngược lại.
   • ViewModel có tham chiếu đến Model nhưng không phải ngược lại.
   • Chế độ xem không có tham chiếu đến Mô hình và ngược lại.

2. Nếu bạn đang sử dụng bộ điều khiển, nó có thể có tham chiếu đến Chế độ xem và ViewModels , mặc dù Bộ điều khiển không phải lúc nào cũng cần thiết như được trình bày trong SwiftUI .

3. Liên kết dữ liệu : chúng tôi tạo trình nghe cho Thuộc tính ViewModel.

class CustomView: UIView {
  var viewModel = MyViewModel {
    didSet {
      self.color = viewModel.color
    }
  }

  convenience init(viewModel: MyViewModel) {
    self.viewModel = viewModel
  }
}


struct MyViewModel {
   var viewColor: UIColor {
      didSet {
         colorChanged?() // This is where the binding magic happens.
      }
   }

   var colorChanged: ((UIColor) -> Void)?
}


class MyViewController: UIViewController {

   let myViewModel = MyViewModel(viewColor: .green)
   let customView: CustomView!

   override func viewDidLoad() {
      super.viewDidLoad()

      // This is where the binder is assigned.
      myViewModel.colorChanged = { [weak self] color in 
        print("wow the color changed")
      }
      customView = CustomView(viewModel: myViewModel)
      self.view = customView
   }
}

sự khác biệt trong thiết lập

1. Logic nghiệp vụ được giữ trong bộ điều khiển cho MVC và ViewModels cho MVVM.
2. Các sự kiện được truyền trực tiếp từ Chế độ xem đến bộ điều khiển trong MVC trong khi các sự kiện được truyền từ Chế độ xem sang ViewModel đến Bộ điều khiển (nếu có) cho MVVM.

Đặc điểm chung

1. Cả MVVM và MVC đều không cho phép View gửi tin nhắn trực tiếp đến Model / s.
2. Cả hai đều có mô hình.
3. Cả hai đều có quan điểm.

Ưu điểm của MVVM

1. Vì ViewModels giữ logic nghiệp vụ, chúng là các đối tượng cụ thể nhỏ hơn giúp chúng dễ dàng kiểm tra đơn vị. Mặt khác, trong MVC, logic nghiệp vụ nằm trong ViewContoder. Làm thế nào bạn có thể tin tưởng rằng một bài kiểm tra đơn vị của bộ điều khiển xem là an toàn toàn diện mà không cần kiểm tra đồng thời tất cả các phương thức và trình nghe? Bạn không thể hoàn toàn tin tưởng vào kết quả kiểm tra đơn vị.
2. Trong MVVM, do logic nghiệp vụ được rút ra khỏi Bộ điều khiển thành các đơn vị ViewModel nguyên tử, kích thước của ViewContoder co lại và điều này làm cho mã ViewContoder dễ đọc hơn.

Ưu điểm của MVC

1. Việc cung cấp logic nghiệp vụ trong bộ điều khiển giúp giảm nhu cầu phân nhánh và do đó các câu lệnh có nhiều khả năng chạy trên bộ đệm hơn, hoạt động hiệu quả hơn trong việc đóng gói logic nghiệp vụ vào ViewModels.
2. Cung cấp logic kinh doanh ở một nơi có thể đẩy nhanh quá trình phát triển cho các ứng dụng đơn giản, trong đó không yêu cầu kiểm tra. Tôi không biết khi nào các bài kiểm tra không bắt buộc.
3. Việc cung cấp logic nghiệp vụ trong ViewContoder dễ nghĩ hơn đối với các nhà phát triển mới.

Từ quan điểm thực tế, MVC (Model-View-Controller) là một mẫu. Tuy nhiên, MVC khi được sử dụng như ASP.net MVC, khi được kết hợp với Entity Framework (EF) và "công cụ quyền lực" là một cách tiếp cận tự động, mạnh mẽ một phần để đưa cơ sở dữ liệu, bảng và cột vào trang web, cho đầy đủ Các hoạt động CRUD hoặc các hoạt động R (Lấy hoặc Đọc). Ít nhất là khi tôi đã sử dụng MVVM, các Mô hình xem tương tác với các mô hình phụ thuộc vào các đối tượng kinh doanh, lần lượt được "làm bằng tay" và sau rất nhiều nỗ lực, người ta đã may mắn có được các mô hình tốt như những gì mà EF đưa ra " -hộp". Từ quan điểm lập trình thực tế, MVC có vẻ là một lựa chọn tốt vì nó cung cấp rất nhiều tiện ích vượt trội, nhưng vẫn có tiềm năng cho tiếng chuông và tiếng còi được thêm vào.

Bổ sung cho nhiều phản hồi được đưa ra, tôi muốn thêm một số phối cảnh bổ sung từ web phía máy khách hiện đại - hoặc Ứng dụng web phong phú quan điểm của .

Thật vậy, ngày nay các trang web đơn giản và các ứng dụng web lớn hơn thường được xây dựng với nhiều thư viện phổ biến như Bootstrap. Được xây dựng bởi Steve Sanderson, Knockout cung cấp hỗ trợ cho mẫu MVVM, mô phỏng một trong những hành vi quan trọng nhất trong mẫu: liên kết dữ liệu thông qua Mô hình xem. Với một chút JavaScript, dữ liệu và logic có thể được triển khai, sau đó có thể được thêm vào các phần tử trang với các data-bindthuộc tính HTML đơn giản , tương tự như sử dụng nhiều tính năng của Bootstrap . Cùng với nhau, hai thư viện này một mình cung cấp nội dung tương tác; và khi kết hợp với định tuyến phương pháp này có thể dẫn đến một cách tiếp cận đơn giản nhưng mạnh mẽ để xây dựng Ứng dụng Trang đơn .

Tương tự, một khung công tác phía máy khách hiện đại như Angular theo mô hình MVC theo quy ước, nhưng cũng thêm một Dịch vụ. Thật thú vị, nó được quảng cáo là Model-View-Any (MVW). (Xem bài đăng này trên Stack Overflow .)

Ngoài ra, với sự gia tăng của các khung web lũy tiến như Angular 2, chúng ta sẽ thấy một sự thay đổi về thuật ngữ và có lẽ là một mẫu kiến ​​trúc mới trong đó Thành phần bao gồm một Chế độ xem hoặc Mẫu và tương tác với một Dịch vụ - tất cả đều có thể được chứa trong một Mô-đun; và một loạt các Mô-đun tạo nên ứng dụng.

Tôi đã từng nghĩ rằng MVC và MVVM là như nhau. Bây giờ vì sự tồn tại của Flux tôi có thể nói sự khác biệt:

Trong MVC, với mỗi chế độ xem trong ứng dụng của bạn, bạn có một mô hình và bộ điều khiển, vì vậy tôi sẽ gọi nó là xem, xem mô hình, xem bộ điều khiển. Mẫu không cho bạn biết cách một khung nhìn có thể giao tiếp với một khung nhìn khác. Do đó, trong các khung khác nhau có các triển khai khác nhau cho điều đó. Ví dụ, có các triển khai trong đó các bộ điều khiển nói chuyện với nhau trong khi trong các triển khai khác có một thành phần khác làm trung gian giữa chúng. Thậm chí có những triển khai trong đó các mô hình khung nhìn giao tiếp với nhau, đó là một sự phá vỡ của mô hình MVC vì mô hình khung nhìn chỉ nên được truy cập bởi bộ điều khiển khung nhìn.

Trong MVVM, bạn cũng có một mô hình xem cho từng thành phần. Mẫu không xác định mức độ ảnh hưởng của mô hình xem, vì vậy, hầu hết các khung chỉ bao gồm chức năng của bộ điều khiển trong mô hình xem. Tuy nhiên, MVVM cho bạn biết rằng dữ liệu của mô hình xem của bạn phải đến từ mô hình, đó là toàn bộ mô hình không nhận biết hoặc tùy chỉnh cho một chế độ xem cụ thể.

Để chứng minh sự khác biệt, hãy lấy mẫu Flux. Mẫu thông lượng cho biết các giao diện khác nhau trong ứng dụng sẽ giao tiếp như thế nào. Mỗi khung nhìn lắng nghe một cửa hàng và thực hiện các hành động bằng cách sử dụng bộ điều phối. Người điều phối lần lượt nói với tất cả các cửa hàng về hành động vừa được thực hiện và các cửa hàng tự cập nhật. Một cửa hàng trong Flux tương ứng với mô hình (chung) trong MVVM. nó không tùy chỉnh cho bất kỳ chế độ xem cụ thể. Vì vậy, thông thường khi mọi người sử dụng React và Flux, mỗi thành phần React thực sự triển khai mẫu MVVM. Khi một hành động xảy ra, mô hình khung nhìn gọi bộ điều phối và cuối cùng nó được cập nhật theo các thay đổi trong cửa hàng, đó là mô hình. Bạn không thể nói rằng mỗi thành phần thực hiện MVC vì trong MVC chỉ có bộ điều khiển có thể cập nhật mô hình xem.

mvc là phía máy chủ và mvvm là phía máy khách (trình duyệt) trong phát triển web.

hầu hết thời gian javascript được sử dụng cho mvvm trong trình duyệt. có nhiều công nghệ phía máy chủ cho mvc.

Nói một cách ngắn gọn - trong MVC Controler biết về chế độ xem (điều khiển), trong khi trong MVVM, ViewModel không biết ai tiêu thụ nó. ViewModel trưng bày các thuộc tính và hành động có thể quan sát được của nó cho bất kỳ ai có thể quan tâm đến việc sử dụng nó. Thực tế đó giúp việc kiểm tra dễ dàng hơn vì không có tham chiếu đến UI trong ViewModel.

Trình điều khiển mô hình xem mật khẩu (thường được gọi là MVC ) là một mẫu thiết kế phần mềm thường được sử dụng để phát triển giao diện người dùng, phân chia logic chương trình liên quan thành ba yếu tố được kết nối với nhau. Điều này được thực hiện để phân tách các biểu diễn thông tin nội bộ khỏi cách thức trình bày và chấp nhận thông tin của người dùng. Theo mô hình kiến ​​trúc MVC tách rời các thành phần chính này cho phép tái sử dụng mã và phát triển song song.

Theo truyền thống được sử dụng cho giao diện người dùng đồ họa máy tính để bàn (GUI), mẫu này đã trở nên phổ biến để thiết kế các ứng dụng web. Các ngôn ngữ lập trình phổ biến như JavaScript, Python, Ruby, PHP, Java và C # có các khung MVC được sử dụng để phát triển ứng dụng web ngay lập tức.

Mô hình

Thành phần trung tâm của mẫu. Đây là cấu trúc dữ liệu động của ứng dụng, độc lập với giao diện người dùng. Nó trực tiếp quản lý dữ liệu, logic và quy tắc của ứng dụng.

Lượt xem

Bất kỳ đại diện của thông tin như biểu đồ, sơ đồ hoặc bảng. Nhiều chế độ xem của cùng một thông tin là có thể, chẳng hạn như biểu đồ thanh để quản lý và chế độ xem dạng bảng cho kế toán.

Bộ điều khiển

Chấp nhận đầu vào và chuyển đổi nó thành các lệnh cho mô hình hoặc khung nhìn.

Ngoài việc phân chia ứng dụng thành các thành phần này, thiết kế bộ điều khiển chế độ xem mô hình của bộ định nghĩa mô hình xác định các tương tác giữa chúng.

Mô hình chịu trách nhiệm quản lý dữ liệu của ứng dụng. Nó nhận đầu vào của người dùng từ bộ điều khiển.

Khung nhìn có nghĩa là một bản trình bày của mô hình theo một định dạng cụ thể.

Bộ điều khiển đáp ứng đầu vào của người dùng và thực hiện các tương tác trên các đối tượng mô hình dữ liệu. Bộ điều khiển nhận đầu vào, tùy chọn xác nhận nó và sau đó chuyển đầu vào cho mô hình.

Mô hình View View View ViewModel (MVVM) là một mẫu kiến ​​trúc phần mềm.

MVVM tạo điều kiện phân tách sự phát triển của giao diện người dùng đồ họa - có thể thông qua ngôn ngữ đánh dấu hoặc mã GUI - từ sự phát triển của logic nghiệp vụ hoặc logic back-end (mô hình dữ liệu). Mô hình khung nhìn của MVVM là một trình chuyển đổi giá trị, có nghĩa là mô hình khung nhìn chịu trách nhiệm phơi bày (chuyển đổi) các đối tượng dữ liệu từ mô hình theo cách mà các đối tượng được quản lý và trình bày dễ dàng. Về mặt này, mô hình khung nhìn là mô hình nhiều hơn một khung nhìn và xử lý hầu hết nếu không phải là tất cả logic hiển thị của khung nhìn. Mô hình khung nhìn có thể triển khai mẫu hòa giải, tổ chức truy cập vào logic back-end xung quanh tập hợp các trường hợp sử dụng được hỗ trợ bởi khung nhìn.

MVVM là một biến thể của mẫu thiết kế Mô hình trình bày của Martin Fowler. MVVM trừu tượng hóa trạng thái và hành vi của một khung nhìn theo cùng một cách, nhưng Mô hình trình bày trừu tượng hóa một khung nhìn (tạo mô hình khung nhìn) theo cách không phụ thuộc vào nền tảng giao diện người dùng cụ thể.

MVVM được phát minh bởi các kiến ​​trúc sư Microsoft Ken Cooper và Ted Peters để đơn giản hóa việc lập trình theo giao diện người dùng theo sự kiện. Mẫu này được tích hợp vào Windows Presentation Foundation (WPF) (hệ thống đồ họa .NET của Microsoft) và Silverlight (dẫn xuất ứng dụng Internet của WPF). John Gossman, một trong những kiến ​​trúc sư WPF và Silverlight của Microsoft, đã công bố MVVM trên blog của mình vào năm 2005.

Mô hình View View ViewModel cũng được gọi là model binder view view, đặc biệt là trong các triển khai không liên quan đến nền tảng .NET. ZK (một khung ứng dụng web được viết bằng Java) và KnockoutJS (một thư viện JavaScript) sử dụng mô hình binder view view.