Controller vs Model: Where do I put the processing of user input?

Question

I'm new to MVC and I'm not using a framework (and I'm not going to).

I'm designing my new web application using MVC.

I have the user input received in Controller. Suppose I have form data and an action to do with it, which can be "insert", "delete" or "update".

Must I have process that action in Controller or in the Model? That is: must I do:

# Controller
if (action == "insert") Model.insert(data)

or

# Controller
Model.process(data, action)

# Model.process
if (action == "insert") self.insert(data)

(language-agnostic example).

What is the "MVC way" to do it?

Answer 1

Your first example is the right one.

if (action == "insert") Model.insert(data)

But you should try to think of it this way: You have an application, and any interface to it (UI, tests, CLI, etc) is simply that - just an interface.

Interfaces to an application tell it what to do, and get data back from it. That's all they do.

So your interface in this example is the controller. The fact that the controller takes the application's output and renders it inside an HTML template is allegedly "coincidental".

On another note, I know you said you're not going to use any existing framework, but you should at least keep the following in mind:

1. Learning how to use a framework is not always smooth and easy, but it's going to take you less time than trying to implement the set of features yourself.
2. You might not be aware yet of all the pitfalls you're going to encounter. These are all covered, in one way or another, in big MVC frameworks.
3. You might not (and probably don't) know all of the current or future requirements for your application. But frameworks already let you develop something simple today and make it easy to add new features tomorrow (because they're built-in, and built so they'll be easily integrated at any point).

I saw your "language-agnostic" examples were pretty much Python. If you like the language, you should know that Django is one of the biggest and most documented MVC frameworks (in general, not just in Python).

Answer 2

I will try to explain by definitions :-

• Models contain or represent the data that users work with. These can be simple view models, which just represent data being transferred between views and controllers; or they can be domain models, which contain the data in a business domain as well as the operations, transformations, and rules for manipulating that data.
• Views are used to render some part of the model as a UI.
• Controllers process incoming requests, perform operations on the model, and select views to render to the user.

So, you should do this in Controller.

Answer 3

You should do it in the controller, definitely.

The model should only represent the current state of your application. Any control of the applications behavior should be handled by the controller, that's it's purpose.

Answer 4

The controller is just the middle man between the view and the model. The example you provided is a poor example of "user input". The example is of CRUD operations required to perform the logic requested by the user from the view.

In this very simple case, the View needs to perform a database action, CRUD. So, in this simple case the controller simply passes the duty to the Model which handles the DB operations.

User input comes into play when you ask "what am I creating?". The user provides information that may need to run through a BL and data input verification process. This is when you need other layers to assist MVC.

Answer 5

When you're interactively editing something, I like to think of there being two "models". There's the "entity model" which is the persisted state, and there's the "edit model" which is the current state of the data during the interactive editing.

These are typically not the same thing. For instance, there are states that are allowable in the edit model which aren't allowed in the entity model (like having not filled out a required field).

So the edit model and entity model (as far as I'm concerned) should both be part of your business layer, because they both contain business rules. I know a lot of people using MVVM think that the ViewModel should be the edit model. I don't think that's a hard and fast rule, and in my current application I'm keeping them separate.

So, Pankaj said:

Controllers process incoming requests, perform operations on the model, and select views to render to the user.

Based on what I've said above, there are two types of actions:

1. Normal edit actions (changing a selection in a drop-down that has an effect on some other field) would interact with the edit model only. The controller then creates a new View based on the new edit model state.
2. "CRUD" operations that commit data should first check the edit model for validity (by calling into the edit model itself), and if valid, should then commit the changes to the entity model by delegating to some kind of "map" method in the models. Typically this commits your changes to a shared data store like a database. Other users can then see the changes.

So the controller handles all input requests, but delegates the work to the model. After the delegation of the work to the model, it then maps the model back onto the View (typically by instantiating a new view and passing in the new state of the edit model).