What's the difference between a ViewModel and Controller?

Question

What are the responsibilities of one vs the other? What kind of logic should go in one vs the other? Which one hits services and databases? How do I decide if my code should go in the viewmodel or the controller?

For the record, I am using ASP MVC, but since the question is architectural, I do not believe it matters what language or framework I am using. I'm inviting all MVC to respond

Answer 1

The ViewModel is a Pattern used to handle the presentation logic and state of the View and the controller is one of the fundamentals parts of any MVC framework, it responds to any http request and orchestrates all the subsequent actions until the http response.

The ViewModel Pattern: More info

In the ViewModel pattern, the UI and any UI logic are encapsulated in a View. The View observes a ViewModel which encapsulates presentation logic and state. The ViewModel in turn interacts with the Model and acts as an intermediary between it and the View.

View <-> ViewModel <-> Model

The Controllers (Comes from the Front Controller Pattern): More Info

It "provides a centralized entry point for handling requests."

HTTP Request -> Controller -> (Model,View)

--Plain Differences:--

• While the ViewModel is an optional pattern the Controller is a must, if you are going the MVC way.
• The ViewModel encapsulates presentation logic and state, The Controller orchestrates all the Application Flow.

Answer 2

• The ViewModel can be on the client side as well as server side. Wherever it may be, the sole purpose of viewmodel is to play the presentation data.
• In MVC architecture Viewmodel is not mandatory but with out controller the request from the client cannot be processed.
• Controller can be visualised as the main interface between client and server to get any response from the server. It processes the client request, fetches data from repository and then prepares the view data. Viewmodel can be visualised as view data processor/presenter thus an interface to manage the view more eloquently.
• In the overall context of a web application we can say the controller is the application request handler whereas viewmodel is only the UI handler.

Answer 3

MVC stands for Model, View, Controller.

Model = Data (Database tables)

View = HTML, CSS, JavaScript, etc

Controller = Main logic, a contract between Model & View.

In simple and graspable terms,

MVC allows you to develop your applications in a way that your business data and presentation data are separated. With this, a developer and designer can work independently on a MVC app without their work clashing. MVC makes your app avail OOP too.

Answer 4

I think there's some value to learning received doctrine. But there is also value in understanding how the doctrine came to be the way it is.

Trygve Reenskaug is widely credited with inventing MVC. N. Alex Rupp's article Beyond MVC: A new look at the servelet architecture includes a History of MVC. In a section on Reenskaug's 1978 work at Xerox Palo Alto Research Center, there's a link to his paper Thing-Model-View-Editor: an Example from a planningsystem. There the pieces are described like this.

Thing

Something that is of interest to the user. It could be concrete, like a house or an integrated circuit. It could be abstract, like a new idea or opinions about a paper. It could be a whole, like a computer, or a part, like a circuit element.

Model

A Model is an active representation of an abstraction in the form of data in a computing system

View

To any given Model there is attached one or more Views, each View being capable of showing one or more pictorial representations of the Model on the screen and on hardcopy. A View is also able to perform such operations upon the Model that is reasonabely associated with that View.

Editor

An Editor is an interface between a user and one or more views. It provides the user with a suitable command system, for example in the form of menus that may change dynamically according to the current context. It provides the Views with the necessary coordination and command messages.

Rupp identifies Reenskaug's Editor as a Controller or Tool.

MVC Triads emerged in SmallTalk-80. The model was an abstraction of the real-world concept, the view was its visual representation, and the controller was the buttons and slider bars that allowed the user to interact with it (thereby "controlling" the view). All pieces in the triad were interconnected and could communicate with the other two pieces, so there was no layering or abstraction involved. Since then, Reenskaug has "preferred to use the term Tool rather then Controller." According to his notes, these are the terms he has used in later implementations

Answer 5

The Model-View-Controller (MVC) is an architectural design pattern which exists, primarily, to separate business logic from the presentation. Basically, you don't want your back-end touching your front. It typically looks like this:

The reasons for doing this is because, by separating the back-end and the front, you don't tie your user-interface directly to your data/work. This allows you to put new interfaces onto your business logic without affecting said logic. In addition, it also improves the ease of testing.

A simple example of where MVC comes in handy - let's say you have an application that manages your company's finances. Now, if you are correctly using MVC, you can have a front end that sits at some financier's desk and lets him handle transactions, manage the finances, etc. BUT, because the business logic is separate, you can also provide a front-end to your CEO's Blackberry that lets him see the current status of the business. Because the two front-ends are different, they can do different things while still providing (different types of) access to the data.

EDIT:

Since you updated your question a bit, I'll update my answer. There is no perfect science to the separation of MVC. There are some good rules of thumb, however. For example, if you are talking about GUI components, that is probably a view. (Are you talking about look and feel, usability, etc.) If you are talking about data and the "business" side of the house (databases, logic, etc), you are probably referring to a model. And, anything that controls the interaction between the two is most likely a controller.

In addition, it should be noted that, while Views and Models are typically "physically" separated, a controller can exist with a view when it makes sense.

You are correct when you say the framework (or even language) for MVC doesn't matter. The pattern itself is language agnostic and really describes a way to architect your system.

Hope that helps!

Answer 6

Some logic and model should be invoked to generate some data (structured or semi-structured). From this data the returned page/JSON/etc. is created, typically with only rudimentary outlining logic.

The first part (creating the data) is done by the controller (via the model usually). The second part - by the View. The ViewModel is the data structure being passed between controller and view, and usually contains only accessors.

Answer 7

Model represents your data and how it's manipulated. Thus, model touches the DB.

View is your UI.

Controler is the glue between them.