MVC vs MVVM: Similarities and Differences
Last updated
Last updated
© Ice Tea Group LLC, All Rights Reserved.
MVC and MVVM are similar architectural approaches, and it can be confusing to understand the difference between the two. We will compare two Wisej.NET projects that achieve the same result- a simple DataGridView that displays information about students, and allows the user to add additional students. One project is written using a MVC approach and the other uses a MVVM approach.
You can view both projects on GitHub here: https://github.com/iceteagroup/wisej-architecture-examples
Let's get the similarities out of the way first- both MVC and MVVM have a View and a Model. In fact, you can use a very similar View and the same Model whether you are using MVC or MVVM! So the difference in MVC vs MVVM really comes down to the difference in the Controller vs the ViewModel.
In MVC, the controller is typically more tightly coupled to the view than the ViewModel is in MVVM and may not be as easily reusable across different views. In our example project, the controller is Page1.cs, and the view is Page1.designer.cs. So, in this case, they are extremely tightly coupled- they're actually part of the same class! Note that you could instead take a less tightly coupled approach, by creating a seperate Controller class. In that case, the Page1.cs part of the code would be known as the code-behind: the part of the code that connects the Controller to the view.
In MVVM, the ViewModel binds to the View. This ensures that data is synchronized between the database and the view as soon as it is changed. (Whereas in MVC, you have to manually call a function to synchronize the data.)
In order to understand how event handlers are set up in MVC vs MVVM, let's look at the simple example of creating a Button with a Click event.
We'll start by creating a Button object in the designer.
The designer-generated code is generated in Page1.Designer.cs. The code that involves creating the Button, as well as setting its location and text belongs in the view. Because our view is Page1.Designer.cs, this code is fine- it doesn't need to be moved or edited.
What about when we attach an event handler to the Button to handle the Click event? That's where we can really see the difference between the MVC and the MVVM approaches. Here's the code that the designer produces when we attach an event handler:
In MVC, this code is fine as-is. Page1.Designer.cs is our View, and it's fine to set up the Click event handler in the view. And Page1.cs is either our controller or our code-behind. Either way, that's the correct place to put the button1_Click()
function. (Note that if Page1.cs is the code-behind, the contents of the button1_Click()
function should consist of calling a function in the controller.)
However, with MVVM, this code is in the wrong place! Both of these code snippets would need to be moved to the ViewModel. The event hander is set up in the constructor of the ViewModel, and the button1_Click()
function is defined as part of the ViewModel class.
So, as you can see, it's a little more intuitive to write MVC code (as compared to MVVM), especially when you are using the designer to edit the view. MVVM can certainly be implemented in Wisej; you just have to know which designer-generated lines of code you need to move to the ViewModel.
MVC is simpler than MVVM, which makes it easier to implement.
With Wisej.NET, the designer generates event handler code in Page1.cs, which makes it very natural to incorporate that code into the code-behind or into the controller.
MVC is harder to maintain than MVVM. Because the controller is so tightly coupled to the view, .
Databinding automatically synchronizes data between the View and the database.
Some designer-generated code (event handlers) will have to be moved to the ViewModel class.