Jaka jest różnica między MVC a MVVM?

Myślę, że najłatwiej zrozumieć, co te akronimy mają znaczyć, to zapomnieć o nich na chwilę. Zamiast tego pomyśl o oprogramowaniu, z którym pochodzą, o każdym z nich. To naprawdę sprowadza się tylko do różnicy między wczesną siecią a pulpitem.

Pierwszy akronim, MVC, pochodzi z sieci. (Tak, być może było to już wcześniej, ale Internet jest tym, jak został spopularyzowany przez masy twórców stron internetowych.) Think database, HTML pages, and code inbetween. Doprecyzujmy to tylko trochę, aby dotrzeć do MVC: dla" bazy danych", Załóżmy, że baza danych plus kod interfejsu. Dla "stron HTML", Załóżmy szablony HTML plus kod przetwarzania szablonu. W przypadku "code inbetween" Załóżmy, że kod mapuje kliknięcia użytkownika na akcje, prawdopodobnie wpływając na bazę danych, zdecydowanie powodując wyświetlenie innego widoku. To wszystko, przynajmniej na potrzeby tego porównania.

Zachowajmy jedną cechę tej sieciowej rzeczy, nie taką, jaka jest dzisiaj, ale taką, jaka istniała dziesięć lata temu, kiedy Javascript był skromną, nikczemną irytacją, której prawdziwi Programiści dobrze się trzymali: strona HTML jest zasadniczo głupia i bierna. Przeglądarka jest cienkim klientem, lub jeśli chcesz, słabym klientem. W przeglądarce nie ma inteligencji. Reguła przeładowania całej strony. "Widok" jest generowany za każdym razem na nowo.

Pamiętajmy, że ten internetowy sposób, mimo że był cały wściekły, był strasznie zacofany w porównaniu do pulpitu. Aplikacje desktopowe są grubymi klientami lub bogatymi klientów. (Nawet program taki jak Microsoft Word może być uważany za rodzaj klienta, klienta dokumentów.) To klienci pełni inteligencji, pełni wiedzy o swoich danych. Mają status Państwowy. Przechowują dane w pamięci. Nie ma takiego gówna jak pełne przeładowanie strony.

I ten bogaty sposób pulpitu jest prawdopodobnie miejscem, w którym powstał drugi akronim, MVVM. Nie daj się zwieść listom, przez pominięcie C. kontrolerzy nadal tam są. Muszą być. Nic nie zostanie usunięte. Dodajemy tylko jedną rzecz: stanowość, dane buforowane na kliencie (a wraz z nią inteligencję do obsługi tych danych). Te dane, zasadniczo pamięć podręczna na kliencie, są teraz nazywane "ViewModel". To pozwala na bogatą interaktywność. I to wszystko.

• MVC = model, kontroler, widok = zasadniczo jednokierunkowa komunikacja = słaba interaktywność
• MVVM = model, kontroler, pamięć podręczna, widok = dwukierunkowa komunikacja = bogata interaktywność

Widzimy że z Flashem, Silverlight i-co najważniejsze-Javascript, sieć przyjęła MVVM. Przeglądarki nie mogą być już legalnie nazywane cienkimi klientami. Spójrz na ich programowalność. Spójrz na ich zużycie pamięci. Spójrz na całą interaktywność Javascript na nowoczesnych stronach internetowych.

Osobiście uważam tę teorię i akronim biznes za łatwiejsze do zrozumienia, patrząc na to, do czego odnosi się w konkretnej rzeczywistości. Pojęcia abstrakcyjne są użyteczne, zwłaszcza gdy są demonstrowane na konkretnych Materia, więc zrozumienie może zapaść w pełne koło.

MVVM Model-View ViewModel jest podobny do MVC, Model-View Controller

Kontroler zostaje zastąpiony przez ViewModel . ViewModel znajduje się pod warstwą interfejsu użytkownika. Model widoku wyświetla obiekty danych i poleceń, których potrzebuje widok. Można to traktować jako obiekt kontenera, z którego view pobiera dane i akcje. ViewModel pobiera dane z modelu.

Russel East czy blog omawia bardziej szczegółowo dlaczego MVVM różni się od MVC

Po pierwsze, MVVM jest progresją wzorca MVC, który używa XAML do obsługi wyświetlacza. Ten artykuł przedstawia niektóre z aspektów tych dwóch.

Głównym założeniem architektury Model / View / ViewModel wydaje się być to, że na szczycie danych ("Model") znajduje się kolejna warstwa elementów niewizualnych ("ViewModel"), które mapują koncepcje danych ściślej do koncepcji widoku danych ("Widok"). To widok, który łączy do, nie do modelu bezpośrednio.

Możesz zobaczyć Wyjaśnienie wzorca MVVM w środowisku Windows:

We wzorze projektowym Model-View-ViewModel aplikacja składa się z trzech ogólnych komponentów.

• Model : przedstawia model danych używany przez aplikację. Na przykład w aplikacji do udostępniania obrazów warstwa ta może reprezentować zestaw obrazów dostępnych na urządzeniu oraz interfejs API używany do odczytu i zapisu obrazu biblioteka.

• Widok : Aplikacja zazwyczaj składa się z wielu stron interfejsu użytkownika. Każda strona wyświetlana użytkownikowi jest widokiem w terminologii MVVM. Widok jest kodem XAML używanym do definiowania i stylizacji tego, co widzi użytkownik. Dane z modelu są wyświetlane użytkownikowi, a zadaniem ViewModel jest podawanie danych interfejsu użytkownika na podstawie bieżącego stanu aplikacji. Na przykład w aplikacji do udostępniania zdjęć widoki byłyby interfejsem użytkownika pokazującym listę albumów na urządzeniu, zdjęcia w albumie, a może inny, który pokazuje użytkownikowi konkretne zdjęcie.

• Viewmodel: ViewModel łączy model danych lub po prostu model z interfejsem użytkownika lub widokami aplikacji. Zawiera logikę, za pomocą której można zarządzać danymi z modelu i eksponować dane jako zestaw właściwości, do których może wiązać się interfejs użytkownika XAML lub widoki. Na przykład w aplikacji do udostępniania zdjęć model widoku wyświetli listę albumów, a dla każdego albumu wyświetli listę albumów. zdjęcia. Interfejs użytkownika jest niezależny od tego, skąd pochodzą zdjęcia i jak są pobierane. Po prostu wie o zestawie zdjęć wystawionych przez ViewModel i pokazuje je użytkownikowi.

Myślałem, że jedną z głównych różnic było to, że w MVC, Twoja V odczytuje Twoje M bezpośrednio i przechodzi przez C, aby manipulować danymi, podczas gdy w MVVM, twoja VM działa jako proxy M, jak również zapewnia dostępną funkcjonalność dla Ciebie v.

Jeśli nie jestem pełen śmieci, dziwię się, że nikt nie stworzył hybrydy, gdzie twoja VM jest tylko proxy M, A C zapewnia całą funkcjonalność.

MVVM jest udoskonaleniem (dyskusyjnym) wzoru Modelu prezentacji. Mówię dyskusyjne, ponieważ jedyną różnicą jest to, w jaki sposób WPF zapewnia możliwość łączenia danych i obsługi poleceń.

Prosta różnica: (zainspirowany kursem Yaakova AngularJS)

MVC (Model View Controller)

1. modele: modele zawierają informacje o danych. Nie wywołuje ani nie używa kontrolera i widoku. Zawiera logikę biznesową i sposoby reprezentacji danych. Niektóre z tych danych, w jakiejś formie, mogą być wyświetlane w widoku. Może również zawierać logikę pobierania danych z jakiegoś źródła.
2. Kontroler: działa jako połączenie między widokiem a modelem. Wyświetl wywołania Controller i Controller wywołują model. Zasadniczo informuje model i / lub widok, aby zmienić odpowiednio.
3. widok: zajmuje się częścią interfejsu użytkownika. Współdziała z użytkownikiem.

MVVM (Model View View Model)

ViewModel :

1. jest to reprezentacja stanu widoku.
2. przechowuje Dane wyświetlane w widoku.
3. odpowiada na wyświetlanie zdarzeń, aka logika prezentacji.
4. wywołuje inne funkcje do przetwarzania logiki biznesowej.
5. nigdy nie prosi widoku o wyświetlenie czegokolwiek.

Model widoku jest "abstrakcyjnym" modelem dla elementów interfejsu użytkownika. Musi umożliwiać wykonywanie poleceń i działań w widoku w sposób niewizualny (na przykład w celu przetestowania).

Jeśli pracowałeś z MVC, prawdopodobnie kiedyś przydało ci się tworzenie obiektów modelowych odzwierciedlających stan twojego widoku, na przykład Pokazywanie i ukrywanie niektórych okien dialogowych edycji itp. W takim przypadku używasz viewmodel.

Wzór MVVM jest po prostu uogólnieniem tej praktyki do wszystkich elementów interfejsu użytkownika.

I nie jest to wzorzec Microsoftu, dołącza się do tego, że wiązania danych WPF / Silverlight są specjalnie przystosowane do pracy z tym wzorzec. Ale nic nie stoi na przeszkodzie, aby używać go na przykład z twarzami serwera java.

MVC jest środowiskiem kontrolowanym, a MVVM środowiskiem reaktywnym.

W kontrolowanym środowisku powinieneś mieć mniej kodu i wspólne źródło logiki; które zawsze powinno żyć w kontrolerze. Jednak; w świecie web MVC łatwo dzieli się na logikę tworzenia widoku i logikę dynamiczną widoku. Tworzenie żyje na serwerze, a dynamika żyje na kliencie. Często to widzisz z ASP.NET MVC w połączeniu z AngularJS natomiast serwer utworzy widok i przekazać Model i wysłać go do klienta. Następnie klient wchodzi w interakcję z widokiem, w którym to przypadku AngularJS staje się kontrolerem lokalnym. Po przesłaniu Model lub nowy Model jest przekazywany z powrotem do kontrolera serwera i obsługiwany. (Tak więc cykl trwa i istnieje wiele innych tłumaczeń tej obsługi podczas pracy z socketami lub Ajaxem itp., ale w całej architekturze jest identyczna.)

MVVM jest środowiskiem reaktywnym, co oznacza, że zazwyczaj piszesz kod (np. wyzwalacze), które zostaną aktywowane na podstawie jakiegoś zdarzenia. W XAML, gdzie rozwija się MVVM, wszystko to jest łatwe do zrobienia z wbudowanym frameworkiem databinding, ale jak wspomniano, będzie to działać na każdym systemie w dowolnym widoku z dowolnym językiem programowania. Nie jest specyficzny dla MS. Model widoku jest wywołany (Zwykle Zdarzenie zmienione właściwością), a Widok reaguje na niego na podstawie utworzonych wyzwalaczy. Może to być techniczne, ale najważniejsze jest to, że widok jest bezpaństwowy i bez logiki. Po prostu zmienia stan na podstawie na wartości. Co więcej, Viewmodele są bezpaństwowe z bardzo małą logiką, a modele są stanem z zasadniczo zerową logiką, ponieważ powinny tylko utrzymywać stan. Opisuję to jako stan aplikacji( Model), translator stanu (ViewModel), a następnie stan wizualny / interakcja (Widok).

W aplikacji MVC desktop lub po stronie klienta powinieneś mieć Model, A Model powinien być używany przez kontroler. Na podstawie modelu kontroler zmodyfikuje Widok. Widoki są zwykle powiązane do kontrolerów z interfejsami, dzięki czemu kontroler może pracować z różnymi widokami. W ASP.NET logika MVC jest nieco cofnięta na serwerze, ponieważ kontroler zarządza modelami i przekazuje modele do wybranego widoku. Widok jest następnie wypełniany danymi bazującymi na modelu i ma własną logikę (zwykle inny zestaw MVC, taki jak AngularJS). Ludzie będą się kłócić i pomylić to z MVC aplikacji i spróbować zrobić oba w którym momencie utrzymanie projektu będzie w końcu stanie się katastrofą. Zawsze umieść logikę i sterowanie w jednym miejscu podczas korzystania z MVC. Nie zapisuj logiki widoku w kodzie za widokiem (lub w widoku przez js dla web), aby pomieścić dane kontrolera lub modelu. Pozwól sterownikowi zmienić widok. Jedyną logiką, która powinna żyć w widoku, jest to, czego potrzeba, aby utworzyć i uruchomić za pośrednictwem interfejsu, którego używa. Przykładem tego jest podanie nazwy użytkownika i hasła. Czy na pulpicie czy na stronie www (na kliencie) Kontroler powinien obsługuje proces submit za każdym razem, gdy widok jest wywołany akcją Submit. Jeśli zrobione poprawnie zawsze można znaleźć drogę wokół MVC Web lub aplikacji lokalnej łatwo.

MVVM jest osobiście moim ulubionym, ponieważ jest całkowicie reaktywny. Jeśli model zmieni stan, ViewModel nasłuchuje i tłumaczy ten stan i to wszystko!!! Widok jest następnie nasłuchuje ViewModel dla zmiany stanu, a także aktualizuje się na podstawie tłumaczenia z ViewModel. Niektórzy nazywają to czystym MVVM, ale jest naprawdę tylko jeden i nie obchodzi mnie, jak to argumentujesz i zawsze jest to czysty MVVM, gdzie widok nie zawiera absolutnie żadnej logiki.

Oto mały przykład: powiedzmy, że chcesz mieć menu wsuwane po naciśnięciu przycisku. W MVC będziesz miał operację MenuPressed w interfejsie. Kontroler będzie wiedział po kliknięciu przycisku Menu, a następnie poinformuje widok, aby przesuwał się w Menu na podstawie innej metody interfejsu, takiej jak SlideMenuIn. Z jakiego powodu? Okryć Kontroler decyduje nie możesz lub nie chcesz zrobić czegoś innego, dlatego. Kontroler powinien być odpowiedzialny za Widok, a widok nie robi nic, chyba że kontroler tak powie. Jednak; w MVVM menu slide w animacji powinno być wbudowane i ogólne i zamiast być informowany, aby slide w zrobi to na podstawie pewnej wartości. Więc słucha ViewModel i kiedy ViewModel mówi, IsMenuActive = true ( lub jednak) animacja dla tego ma miejsce. Teraz, z tym, że powiedział Chcę, aby inny punkt Naprawdę jasne i proszę zwrócić uwagę. IsMenuActive to prawdopodobnie zły projekt MVVM lub ViewModel. Projektując ViewModel nigdy nie należy zakładać, że Widok będzie miał jakiekolwiek funkcje i po prostu przejdzie przetłumaczony stan modelu. W ten sposób, jeśli zdecydujesz się zmienić widok, aby usunąć Menu i po prostu pokazać dane / opcje w inny sposób, ViewModel ma to gdzieś. Więc jak zarządzasz Menu? Kiedy dane mają sens. Tak więc jednym ze sposobów na to jest nadanie Menu listy opcji (prawdopodobnie szereg wewnętrznych widoków). Jeśli ta lista zawiera dane, Menu wie, aby otworzyć za pomocą wyzwalacza, jeśli nie, to wie, aby ukryć za pomocą wyzwalacza. Po prostu masz dane do menu lub nie w ViewModel. Nie decyduj się na Pokazywanie / ukrywanie tych danych w ViewModel.. po prostu Przetłumacz stan modelu. W ten sposób Widok jest całkowicie reaktywny i ogólny i może być używany w wielu różnych sytuacjach.

Wszystko to prawdopodobnie nie ma absolutnie żadnego sensu, jeśli nie jesteś jeszcze przynajmniej nieco zaznajomieni z architekturą każdego z nich i nauka może być bardzo myląca, ponieważ znajdziesz wiele złych informacji w sieci.

Więc... rzeczy, o których należy pamiętać, aby to zrobić dobrze. Zdecyduj z góry, jak zaprojektować swoją aplikację i trzymaj się jej.

Jeśli robisz MVC, co jest świetne, upewnij się, że kontroler jest zarządzalny i ma pełną kontrolę nad Twoim widokiem. Jeśli masz duży widok, rozważ dodanie kontrolek do widoku, które mają różne kontrolery. JUST Nie kaskaduj tych kontrolerów do różnych kontrolerów. Bardzo frustrujące w utrzymaniu. Poświęć chwilę i zaprojektuj rzeczy osobno w sposób, który będzie działał jako oddzielne komponenty... I zawsze pozwól kontrolerowi powiedzieć modelowi, aby zatwierdził lub utrzymał pamięć masową. Idealną konfiguracją zależności dla MVC in jest View ← Controller → Model lub z ASP.NET (don ' t get me started) Model ← widok ↔ kontroler → Model (gdzie Model może być tym samym lub zupełnie innym modelem od kontrolera do Widok) ...oczywiście jedyną potrzebą, aby wiedzieć o kontrolerze w widoku w tym momencie, jest głównie dla endpoint reference, aby wiedzieć, gdzie z powrotem przekazać Model.

Jeśli robisz MVVM, błogosławię twoją dobrą duszę, ale poświęć czas, aby zrobić to dobrze! Nie używaj interfejsów dla jednego. Niech twój widok zdecyduje, jak to będzie wyglądać w oparciu o wartości. Zagraj z widokiem z makiet danych. Jeśli w końcu masz widok, który pokazuje Menu (jak na przykładzie), nawet jeśli nie chcesz go w tym czasie, to dobrze. Twój widok działa tak, jak powinien i reaguje na podstawie wartości tak, jak powinien. Wystarczy dodać kilka dodatkowych wymagań do wyzwalacza, aby upewnić się, że tak się nie stanie, gdy model ViewModel znajduje się w określonym przetłumaczonym stanie lub polecić modelowi ViewModel opróżnienie tego stanu. W Twoim Viewmodelu nie usuwaj tego z wewnętrzną logiką, tak jakbyś decydował od tego, czy Widok powinien go zobaczyć, czy nie. Pamiętaj, że nie możesz zakładać, że w ViewModel jest menu lub nie. I wreszcie Model powinien po prostu pozwolić Ci zmienić i najprawdopodobniej stan przechowywania. To jest miejsce, gdzie Walidacja i wszystko będzie miało miejsce; na przykład, jeśli Model nie może zmodyfikować stanu, to po prostu oznaczy się jako brudny lub coś w tym stylu. Kiedy ViewModel to sobie uświadomi, przetłumaczy to, co jest brudne, a Widok zda sobie z tego sprawę i wyświetli pewne informacje za pomocą innego wyzwalacza. Wszystkie dane w widoku mogą być przypisane do ViewModel, więc wszystko może być dynamiczne tylko Model i ViewModel nie ma absolutnie żadnego pojęcia o tym, jak widok zareaguje na powiązanie. W rzeczywistości Model nie ma również pojęcia o ViewModel. Podczas konfigurowania zależności powinny one wskazywać tak i tylko tak View → ViewModel → Model (i uwaga dodatkowa tutaj... i to pewnie też będzie się kłócić, ale nie obchodzi mnie to... Nie przekazuj modelu do widoku. Widok nie powinien widzieć okresu modelowego. Obchodzi mnie co widziałeś albo jak to zrobiłeś, to jest złe.)

Oto moja ostatnia wskazówka... Spójrz na dobrze zaprojektowaną, ale bardzo prostą aplikację MVC i zrób to samo dla aplikacji MVVM. Jeden będzie miał większą kontrolę z ograniczoną do zera elastycznością, podczas gdy drugi nie będzie miał kontroli i nieograniczonej elastyczności.

Kontrolowane środowisko jest dobre do zarządzania całą aplikacją z zestawu kontrolerów lub (z jednego źródła), podczas gdy środowisko reaktywne można podzielić na oddzielne repozytoria bez absolutnie żadnego pojęcia, co robi reszta aplikacji. Zarządzanie mikro vs bezpłatne zarządzanie.

Jeśli nie pomyliłem cię wystarczająco, spróbuj skontaktować się ze mną... Nie mam nic przeciwko omówieniu tego w pełni szczegółowo z ilustracjami i przykładami.

W końcu wszyscy jesteśmy programistami i z tą anarchią żyje w nas podczas kodowania... Więc zasady zostaną złamane, teorie się zmienią, a wszystko to skończy się na umyciu Wieprza... Ale pracując nad dużymi projektami i dużymi zespołami, naprawdę pomaga uzgodnić wzór projektowy i wyegzekwować go. One day to sprawi, że małe dodatkowe kroki podjęte na początku staną się skokami i ograniczeniami oszczędności później.

MVVM dodaje model widoku do mieszanki. Jest to ważne, ponieważ pozwala na korzystanie z wielu wiążących podejść WPF, bez umieszczania wszystkich specyficznych elementów interfejsu użytkownika w zwykłym modelu.

Może się mylę, ale nie jestem pewien, czy MVVM naprawdę zmusza kontroler do miksu. Uważam, że koncepcja jest bardziej zgodna z: http://martinfowler.com/eaaDev/PresentationModel.html . myślę, że ludzie decydują się połączyć go z MVC, a nie, że jest wbudowany w wzór.

Z tego, co mogę powiedzieć, MVVM mapuje do MV MVC - co oznacza, że w tradycyjnym wzorcu MVC V nie komunikuje się bezpośrednio z M. w drugiej wersji MVC, istnieje bezpośredni związek między M I V. MVVM wydaje się brać wszystkie zadania związane z komunikacją M I V, i łączyć ją, aby oddzielić ją od C. W efekcie nadal istnieje większy zakres przepływu pracy aplikacji (lub implementacja scenariuszy użycia), które nie są w pełni uwzględnione w MVVM. To jest rola kontroler. Usuwając te aspekty niższego poziomu ze sterowników, są one czystsze i ułatwia modyfikowanie scenariusza użytkowania aplikacji i logiki biznesowej, a także czyni Kontrolery bardziej wielokrotnego użytku.

Wstrzykiwanie silnie wpisanych ViewModels do widoku za pomocą MVC

1. kontroler jest odpowiedzialny za nowe dodanie modelu widoku i wstrzyknięcie go do widoku. (dla żądań get)
2. ViewModel jest kontenerem DataContext i view state, np. ostatni wybrany element itd.
3. Model zawiera encje DB i jest bardzo zbliżony do schematu DB, który wykonuje zapytania i filtruje. (Za to lubię EF i LINQ)
4. Model powinien również uwzględniać repozytoria i lub rzutowanie wyników na silne typy (EF ma świetną metodę... EF.Baza danych.Select (querystring, parms) for direct ADO access to inject queries and get back strong types. Ten adres EF jest powolny argument. EF nie jest powolny!
5. Model widoku pobiera dane i wykonuje reguły biznesowe i walidację
6. kontroler na post back spowoduje wywołanie metody ViewModel Post i oczekiwanie na wyniki.
7. kontroler wprowadzi nowo zaktualizowany Viewmodel do widoku. Widok używa tylko silnego wiązania typu .
8. widok jedynie renderuje Dane i wysyła zdarzenia z powrotem do kontrolera. (patrz przykłady poniżej)
9. MVC przechwytuje żądanie przychodzące i kieruje je do odpowiedniego kontrolera z silnym typem danych

W tym modelu nie ma kontaktu z obiektami request lub response na poziomie HTTP , ponieważ maszyna MSFT MVC ukrywa to przed nami.

W wyjaśnieniu punktu 6 powyżej (na życzenie)...

Załóżmy, że ViewModel wygląda tak:

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!";
 }
}

Metoda kontrolera posta będzie wyglądać tak (patrz poniżej), zauważ, że instancja mvm jest automatycznie instancjowana przez mechanizmy wiążące MVC. Nigdy nie musisz spadać do warstwy ciągu zapytania w wyniku! To MVC tworzy instancję modelu widoku dla Ciebie na podstawie ciągów zapytań!

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

Zauważ, że aby powyższa akcja działała zgodnie z twoim zamiarem, musisz mieć null ctor zdefiniował, że intializuje rzeczy nie zwrócone w poście. Post back musi również dodawać pary nazwa/wartość dla tych rzeczy, które się zmieniły. Jeśli brakuje par nazwa / wartość, silnik wiążący MVC robi właściwą rzecz, która jest po prostu niczym! Jeśli tak się stanie, możesz powiedzieć "tracę dane na plecach postów"...

Zaletą tego wzorca jest to, że ViewModel wykonuje wszystkie "bałagany" związane z logiką modelu/Buisness, kontroler jest tylko swego rodzaju router. To SOC w akcji.

Dziwi mnie, że jest to bardzo głosowana odpowiedź, nie wspominając o pochodzeniu MVVM. MVVM jest popularnym terminem używanym w społeczności Microsoft i pochodzi {[2] } z modelu prezentacji Martina Fowlera . Aby zrozumieć Motyw wzoru i różnice w stosunku do innych, pierwszą rzeczą do przeczytania jest oryginalny artykuł o wzorze.

Cóż, ogólnie MVC jest używany w tworzeniu stron internetowych, a MVVM jest najbardziej popularny w WPF / Silverlight development. Jednak czasami architektura sieci Web może mieć mieszankę MVC i MVVM.

Na przykład: możesz użyć knockout.js i w tym przypadku będziesz miał MVVM po stronie klienta. A strona serwera MVC również może się zmienić. W złożonych aplikacjach nikt nie używa czystego modelu. To może mieć sens, aby użyć ViewModel jako "Model" MVC i twój prawdziwy Model w zasadzie będzie część tej maszyny wirtualnej. Daje to dodatkową warstwę abstrakcji.

MVVMC, a może MVC+, wydaje się być realnym podejściem zarówno dla przedsiębiorstw, jak i szybkiego tworzenia aplikacji. Chociaż dobrze jest oddzielić interfejs od logiki biznesowej i interakcji, "czysty" wzór MVVM i większość dostępnych przykładów najlepiej działają na pojedynczych widokach.

Nie jestem pewien twoich projektów, ale większość moich aplikacji zawiera jednak strony i kilka widoków (wielokrotnego użytku), a zatem modele widoków muszą w pewnym stopniu współdziałać. Używanie strony jako kontrolera pokonałoby celem MVVM w ogóle, więc nie za pomocą podejścia "VM-C" dla podstawowej logiki może spowodować .. cóż .. trudne konstrukcje w miarę dojrzewania aplikacji. Nawet w VB-6 większość z nas prawdopodobnie przestała kodować logikę biznesową do zdarzenia przycisku i zaczęła "przekazywać" polecenia do kontrolera, prawda? Ostatnio przyjrzałem się wielu powstającym framworks na ten temat; moim ulubionym jest oczywiście podejście Magellan (w codeplex). Szczęśliwego kodowania!

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

Z praktycznego punktu widzenia MVC (Model-View-Controller) jest wzorcem. Jednak MVC, gdy jest używany jako ASP.net MVC, w połączeniu z Entity Framework (EF) i" elektronarzędziami " jest bardzo potężnym, częściowo zautomatyzowanym podejściem do przenoszenia baz danych, tabel i kolumn na stronę internetową, do pełnych operacji CRUD lub tylko operacji R (pobieranie lub odczyt). Przynajmniej tak jak używałem MVVM, modele widoków współdziałały z modelami zależnymi od obiektów biznesowych, które z kolei były " ręcznie robione" i po wielu wysiłkach, jeden miał szczęście, aby uzyskać modele tak dobre, jak to, co EF daje jeden "out-of-the-box". Z praktycznego punktu widzenia programowania, MVC wydaje się dobrym wyborem, ponieważ daje wiele narzędzi out-of-box, ale nadal istnieje potencjał dzwonków i gwizdków do dodania.

Uzupełniając wiele udzielonych odpowiedzi, chciałem dodać trochę dodatkowej perspektywy z punktu widzeniaModern client-side web - orRich Web Application .

Rzeczywiście w dzisiejszych czasach proste strony internetowe i większe aplikacje internetowe są powszechnie zbudowane z wielu popularnych bibliotek, takich jak Bootstrap. Zbudowany przez Steve ' a Sandersona, Knockout zapewnia wsparcie dla wzorca MVVM, który naśladuje jedno z najważniejszych zachowań we wzorcu: wiązanie danych przez model widoku. Przy odrobinie JavaScript można zaimplementować Dane i logikę, które można następnie dodawać do elementów strony z prostymi atrybutami data-bind HTML, podobnie jak przy użyciu wielu funkcji Bootstrap. Razem te dwie biblioteki oferują interaktywną zawartość; a w połączeniu z routingiem takie podejście może skutkować prostym, ale potężnym podejściem do budowy Jednostronicowej aplikacji.

Podobnie, Nowoczesny Framework po stronie klienta, taki jak Angular podąża za wzorcem MVC według konwencji, ale także dodaje usługę. Co ciekawe, jest reklamowany jako Model-View-Whatever (MVW). (Zobacz ten post na Stack Overflow.)

Dodatkowo, wraz z rozwojem progresywnych frameworków internetowych, takich jak Angular 2, obserwujemy zmianę terminologii i być może Nowy Wzór architektoniczny, w którym Komponenty składają się z widoku lub szablonu i wchodzą w interakcję z Usługą - z których wszystkie mogą być zawarte w Module; A seria modułów składa się z widoku lub szablonu. wniosek.

Kiedyś myślałem, że MVC i MVVM to to samo. Teraz z powodu istnienia Flux mogę odróżnić:

W MVC, dla każdego widoku w Twojej aplikacji, masz model i kontroler, więc nazwałbym go view, view model, view controller. Wzór nie mówi ci, jak jeden widok może komunikować się z innym. Dlatego w różnych frameworkach istnieją różne implementacje tego. Na przykład są Implementacje, w których Kontrolery rozmawiają ze sobą, podczas gdy w inne implementacje istnieje inny komponent, który pośredniczy między nimi. Istnieją nawet implementacje, w których modele widoku komunikują się ze sobą, co jest złamaniem wzorca MVC, ponieważ model widoku powinien być dostępny tylko przez kontroler widoku.

W MVVM masz również model widoku dla każdego komponentu. Wzorzec nie określa, w jaki sposób Widok powinien wpływać na model widoku, więc zazwyczaj większość frameworków zawiera tylko funkcjonalność kontrolera w widoku model. Jednak MVVM mówi, że dane modelu widoku powinny pochodzić z modelu, który jest całym modelem, który nie jest świadomy lub niestandardowy do określonego widoku.

Aby wykazać różnicę, weźmy wzór strumienia. Wzór Flux mówi, Jak różne widoki w aplikacji powinny się komunikować. Każdy widok nasłuchuje magazynu i uruchamia akcje za pomocą dyspozytora. Dyspozytor z kolei informuje wszystkie sklepy o akcji, która została właśnie wykonana, a sklepy aktualizują się same. Sklep w Flux odpowiada (ogólnemu) modelowi w MVVM. to nie jest zwyczaj do żadnego konkretnego widoku. Tak więc zwykle, gdy ludzie używają Reacta i Flux, każdy komponent Reactowy faktycznie implementuje wzorzec MVVM. Gdy wystąpi akcja, model widoku wywołuje dyspozytora, a na koniec jest aktualizowany zgodnie ze zmianami w sklepie, którym jest model. Nie można powiedzieć, że każdy komponent implementuje MVC, ponieważ w MVC tylko kontroler może zaktualizować model widoku. Więc MVVM może współpracować z Flux razem (MVVM obsługuje komunikację pomiędzy widokiem a modelem widoku, a Flux obsługuje komunikację między różnymi widokami), podczas gdy MVC nie może pracować z Flux bez złamania kluczowej Zasady.

Inne odpowiedzi mogą nie być łatwe do zrozumienia dla kogoś, kto nie jest zbyt zaznajomiony z tematem wzorów architektonicznych. Ktoś, kto jest nowy w architekturze aplikacji, może chcieć wiedzieć, jak jej wybór może wpłynąć na jej aplikację w praktyce i o co chodzi w społecznościach.

Próbując rzucić trochę światła na powyższe, wymyśliłem scenariusz z udziałem MVVM, MVP i MVC. Historia zaczyna się od kliknięcia przycisku "Znajdź" w aplikacji wyszukiwania filmów...:

Użytkownik: Klik …

View : kto to? [MVVM / MVP / MVC ]

User: właśnie kliknąłem w przycisk Szukaj ...

widok : ok, poczekaj chwilę ... . [MVVM / MVP / MVC ]

( View wywołanie ViewModel|prezenter|kontroler ... ) [MVVM / MVP / MVC ]

View : Hey ViewModel|prezenter|kontroler , użytkownik właśnie kliknął przycisk wyszukiwania, co mam zrobić? [MVVM / MVP / MVC ]

ViewModel|prezenter|Controller : Hey View , czy na tej stronie jest jakieś Szukane hasło? [MVVM / MVP / MVC ]

View: Yes, ... here it is ... " piano "[MVVM / MVP|MVC ]

-- to jest najważniejsza różnica między MVVM A MVP|MVC ---

prezenter: Thanks View , ... tymczasem Szukam szukanego wyrażenia na Model , pokaż mu/jej pasek postępu [MVP|MVC ]

( prezenter|kontroler wywołuje model ... ) [ MVP|MVC ]

ViewController: dzięki, będę szukał szukanego wyrażenia w modelu , ale nie będę bezpośrednio aktualizował. Zamiast tego wyzwalam zdarzenia do searchResultsListObservable, jeśli jest jakiś wynik. Więc lepiej to obserwuj. [MVVM ]

(obserwując na dowolnym trigger w Searchresultslistobservable, Widok uważa, że powinien pokazywać pasek postępu użytkownikowi, ponieważ ViewModel nie będzie z nim rozmawiać)

------------------------------

ViewModel|prezenter|kontroler : Hej Model , Czy masz jakieś dopasowanie do tego szukanego terminu?: "piano" [MVVM|MVP|MVC ]

Model: Hey ViewModel|Prezenter|Controller , pozwól mi sprawdzić ... [MVVM|MVP|MVC ]

( Model {[8] } robi zapytanie do bazy filmów...) [MVVM|MVP|MVC ]

( po chwili...)

- - - - to jest punkt rozbieżny między MVVM, MVP i MVC -----

Model : znalazłem dla Ciebie listę, ViewModel|prezenter, tutaj jest w JSON "[{"nazwa": "Piano Nauczyciel","rok": 2001}, {"nazwa": "fortepian", "Rok":1993}]" [MVVM|MVP ]

Model: Jest jakiś wynik dostępny, Kontroler. Utworzyłem zmienną pola w mojej instancji i wypełniłem ją wynikiem. Jego nazwa to " searchResultsList "[MVC ]

(prezenter|Controller thanks Model and gets back to the View) [MVP|MVC ]

prezenter: Thanks for waiting View , Znalazłem listę pasujących wyników dla Ciebie i uporządkowałem je w reprezentacyjnym formacie: ["Piano Teacher 2001", "Piano 1993"]. Również Proszę teraz ukryć pasek postępu [ MVP ]

Controller : Thanks for waiting View , I have asked Model about your search query. Mówi, że znalazł listę pasujących wyników i zapisał je w zmiennej o nazwie "searchResultsList" wewnątrz swojej instancji. Możesz go stamtąd wyciągnąć. Również proszę ukryć pasek postępu teraz [MVC ]

ViewModel : każdy obserwator na searchResultsListObservable być powiadomiony, że istnieje ta nowa lista w prezentowalnym formacie: ["Piano Teacher 2001", "Piano 1993"].[MVVM ]

View : Thank you very much Presenter [ MVP]

View : Thank you " Controller" [MVC] (Terazwidok zadaje sobie pytanie: jak przedstawić użytkownikowi wyniki uzyskane z modelu ? Czy Rok produkcji filmu come first or last...?)

View: Oh, JEST NOWY WYZWALACZ w searchResultsListObservable ..., dobrze, jest prezentowalna lista, teraz muszę ją tylko pokazać na liście. Powinienem również ukryć pasek postępu teraz, gdy mam wynik. [MVVM ]

Jeśli jesteś zainteresowany, napisałem serię artykułów tutaj , porównując MVVM, MVP i MVC poprzez wdrożenie aplikacji do wyszukiwania filmów na Androida.

Kontroler nie jest zastępowany przez ViewModel w MVVM, ponieważ ViewModel ma zupełnie inną funkcjonalność niż Kontroler. Nadal potrzebujesz kontrolera, ponieważ bez kontrolera twój Model, ViewModel i View niewiele zdziałają... W MVVM masz też Kontroler, nazwa MVVM jest po prostu missleading.

MVVMC jest poprawną nazwą moim skromnym zdaniem.

Jak widać ViewModel jest tylko dodatkiem do wzorca MVC. Przenosi konwersję-logikę (np. konwertuje obiekt na łańcuch znaków) z kontrolera na model widoku.

Mvc jest po stronie serwera, a mvvm po stronie klienta (przeglądarki) w tworzeniu stron internetowych.

Większość czasu javascript jest używany do mvvm w przeglądarce. istnieje wiele technologii po stronie serwera dla mvc.