Szczerze można wchodzi tutaj w teoretyzowanie ale tak naprawdę nie jest to istotne. MVVM jest do XAML'a pod każdą postacią, MVC to Windows Forms ale częściej ASP.NET. I nie warto wnikać w to jak się nazywa wzorzec z którego aktualnie korzystasz, ważne żeby dobrze Ci się korzystało :) Często jeszcze powstają jakieś warjacje z tych wzorców i czy warto spędzać czas nad wymyślaniem nazwy na to?

Masz wątpliwość czym się tak naprawdę różni ViewModel od Controlera. A więc na mój rozum we wzorcu MVVM widok ZAWIERA ViewModel i komunikacja może następować zarówno z View do VM jak i na odwrót (VM może informować że coś się w nim zmieniło, zaś View mówi dla VM'a co ma wykonać). Przy kontrolerze tak nie jest, kontroler może ZWRÓCIĆ widok i ten widok może komunikować się z kontrolerem, ale kontroler już z widokiem nie bardzo.

Jak się w czymś pomyliłem to ktoś mnie poprawi - ale jeszcze raz podkreślę że nie warto w to wnikać, należy tworzyć architekturę tak żeby było jak najwygodnie dla programisty pisać kod i później nim zarządząc.

Znaczy bo widzisz... tak sobie myślę, ze dobrze jest stosować jakiś konkretny wzorzez w odpowiednich wypadkach bo zwyczajnie uprzyjemna i przyspiesza pracę. W takim razie już rozumiem ;) spoko ;)

Ja mogę spróbować wyjaśnić MVVM.

Tak jak zostało napisane, w aplikacji mamy wyróżnione 3 warstwy:

• View - UI (XAML i CodeBehind) - powinien zawierać tylko elementy wizualne i logikę UI.
• ViewModel - warstwa pośrednia.
• Model - Dane (obiekty biznesowe i servicey) - odpowiada za reprezentację, pozyskanie i modyfikację danych.

W uproszczeniu, wzorzec opiera się na tym, że warstwy nie wiedzą o strukturze innych warstw i mogą komunikować się tylko z sąsiednią klasą. Przy czym:

• ViewViewModel - nie mogą zawierać wzajemnych referencji. Komunikacja tylko przez DataBinding (ew. inne wzorce - messenger, event agregation).
• ViewModelModel - model nie może zawierać referencji do VM, ale VM może zawierać referencję do modelu.
• ViewModel - wszelka komunikacja jest zakazana.

Nie można powiedzieć, że View zawiera ViewModel. Jest to spore uproszczenie i odejście od głównej zasady (wiedza o strukturze innych warstw). Bo skoro View zawiera referencję, to zna typ (czyli strukturę) ViewModelu.

Początkowo zrozumienie tego może być trudne, ale z praktyką się rozjaśnia ;)

Witam

Wiele koncepcji na temat tych dwóch wzorców w w/w postach nie jest prawidłowa. Przede wszystkim - WARTO! poznawać architektury trójwarstwowe, i znać ich idee. Nieznajomość MVC, czy MVP, i jednoczesne stosowanie wzorca powoduje stłumienie cech, które ono posiada (Testowalnosc, Elastycznosc, Rozszerzalnosc, itd.) Dodatkowo ViewModel, ktory jest "Modelem" zbindowanym do widoku, często posiadającym warstwę walidacji, nie jest w zadnym stopniu zwiazany z VM ze wzorca. Tak na prawdę MVVM jest szczególną odmianą MVP (model-view-presenter), której głównym założeniem jest odcięcie wszelkich zależności od widoku poprzez reprezentację w postaci interfejsu, który wprowadza modyfikacje na samym widoku. Prostymi słowami oznacza to, że jeżeli zastosowano poprawnie architekturę MVP(w szczegolnym wypadku MVVM), to możemy ten sam kod zastosowac dla roznych UI (Silverlight, WPF, itd). Zasada działania jest taka : Prezenter(ViewModel) korzysta, i modyfikuje model. Widok obserwuje ten stan, i jeżeli zobaczy zmianę stanu modelu, to się aktualizuje. Szczególny przypadek został opisany przez "dstarkowski". 

MVC - ma troche inne założenia. Wzorzec jest zdeterminowany na przypadki użycia - czyli na czynności wykonywane przez użytkownika końcowego. Kontroler zawiera zestaw takich czynności, i korzystając z modelu (zasobu danych, reprezentującego np. przez instancje klas) generuje widok. Tutaj mamy "twarde" połączenie widoku z kontrolerem (kontroler wywołuje widok), i nie jest już tak łatwo wrzucić inne UI do logiki kodu. Zyskujemy natomiast aplikację zdeterminowaną na przypadki użycia, a sam kod spełnia wszystkie zasady SOLID. Inaczej mówiąc - wszystko się dzieje w kontrolerze :)