Coder Perfect

What is difference between MVC, MVP & MVVM design pattern in terms of coding c#


If we search Google for “distinctions between MVC, MVP, and MVVM design pattern,” we may get a few URLs that theoretically address the differences between MVC, MVP, and MVVM design patterns, such as:


When binding with a “dataContext” isn’t possible, use this method. This is exemplified by Windows Forms. A presenter is required to separate the view from the model. Information must be given to the view via an interface since the view cannot directly bind to the presenter (IView).


When binding via a “dataContext” is possible, use this method. Why? Each view’s numerous IView interfaces have been deleted, resulting in less code to maintain. Some examples of MVVM projects that use Knockout include WPF and javascript projects.


When the link between the view and the rest of the application isn’t always available (and you can’t use MVVM or MVP efficiently), use this technique. This depicts the circumstance in which a web API is isolated from the data supplied to client browsers. Microsoft’s ASP.NET MVC provides a very clear MVC architecture and is a wonderful tool for dealing with such circumstances.

However, I have yet to come across a single article that explains the difference theoretically and includes sample code.

It would be fantastic if I could find an article that explains the differences between these three design patterns (MVC, MVP, and MVVM), as well as code examples.

I’d like to get my hands on the source code for three identical CRUD apps that these three design patterns have implemented (MVC, MVP & MVVM). So that I can go over the code and see how these three design patterns should be implemented (MVC, MVP & MVVM).

So, if there is an article that outlines how the code for these three design patterns (MVC, MVP, and MVVM) differs, please refer me to it.

Asked by Thomas

Solution #1

In a nutshell, the following are the differences:


Where there is a traditional MVC, there is a


The Presenter replaces the Controller in classic MVC. However, unlike the Controller, the Presenter is also in charge of modifying the view. The presenter is rarely called by the perspective.


The presence of View Model distinguishes this case. The VM is a form of implementation of the Observer Design Pattern, in which changes in the model are also represented in the view. For example, if a slider is moved, not only is the model updated, but the data presented in the view, which could be text, is also modified. As a result, data binding is two-way.

Answered by Pritam Banerjee

Solution #2


MVC (old one)

Because of its reduced coupling, MVP is more modular. The Presenter is a go-between between the View and the Model.)

MVVM is an acronym for “Most Valuable (You already have two-way binding between VM and UI component, so it is more automated than MVP)

Another image:

Answered by Uddhav P. Gautam

Solution #3 has a great explanation:

Let’s start with MVC.

The controller receives the input first, not the view. That information may come from a user interacting with a page, or it could simply come from typing a URL into a browser. It’s a Controller in either scenario, and it’s used to start up certain functionality.

Between the Controller and the View, there is a many-to-one link. Because a single controller can render several views depending on the operation being performed, this is the case.

From Controller to View, there is only one direction arrow. Because the View has no knowledge of or reference to the controller, this is the case.

The Model is returned by the Controller, indicating that there is knowledge between the View and the expected Model being put into it, but not between the View and the Controller serving it up.

Model View Presenter (MVP) is a term that refers to a person who can

Let’s have a look at the MVP pattern now. Except for a few significant differences, it appears to be extremely similar to MVC:

The View, not the Presenter, provides the initial input.

The View and the related Presenter have a one-to-one relationship.

The Presenter is referenced by the View. The Presenter is also aware of the View it is associated with because it reacts to events triggered by the View.

The Presenter changes the View depending on the Model’s specified actions, but the View is unaware of the Model.

Model View View Model (MVVM) is an acronym for Model View View Model.

So, now that we’ve looked at the MVC and MVP patterns, let’s look at the MVVM pattern and see what differences it has:


The View Model has no information about the View, despite the fact that the View has a reference to it. This is why a one-to-many mapping between several Views and a single View Model is possible…even across technologies. A View Model could be shared by a WPF View and a Silverlight View, for example.

Answered by taha027

Solution #4



Between Model and View, there will be a Presenter. Presenter will retrieve data from Model, perform data manipulations as desired by the view, and then provide the data to the view, who is solely responsible for rendering.


1)We can’t utilize presenter for numerous modules since only one view class can modify data in presenter.

3)Breaking the Clean architecture since data should only flow outwards, but data is being returned from the presenter to the View.



Between the view and the model, we have a controller. Data will be requested from the controller to the view, but data will be returned to the view in the form of an interface rather than the controller. As a result, the controller will not become bloated as a result of the large number of transactions.


View should manipulate data as it sees fit, as this may add extra work to the UI thread, which may affect UI rendering if data processing is extensive.


Following the announcement of Architectural components, we had access to ViewModel, which presented us with the most significant benefit: it is lifecycle aware. As a result, if the view is unavailable, it will not inform the data. Because the flow is exclusively in forward mode, the design is clean, and data is automatically notified by LiveData. As a result, Android recommends this architecture.

Even MVVM has a drawback. Because it is a lifecycle-aware software, various ideas such as alarms and reminders should be brought in from outside the app. As a result, we won’t be able to use MVVM in this situation.

Answered by Tarun A

Solution #5

The image below is taken from Erwin van der Valk’s article:

The changes are explained in this article, along with several C# code examples.

Answered by Jeremiah Flaga

Post is based on