Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
Look at how the Struts Framework implemented MVC, it will definitely help you in your implementation (Struts is known as the Grand-Daddy of MVC). –  Buhake Sindi Sep 21 '11 at 14:13
    
Yeah, its already answered but I just wanted to add: Controller. –  AJC Sep 21 '11 at 14:26
    
Thank you for all answers; I learned a lot from them. I feel there's a Business Layer near between the Model and the Controller for some cases. –  Sony Santos Sep 22 '11 at 7:06
add comment

5 Answers

up vote 2 down vote accepted

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).

share|improve this answer
    
Actually I work in Ruby, which has many similarities with Python. Ruby has Rails, but I don't like Rails (hard to learn, hard to change the way it works, hard to understand rake, deployment, Apache integration, etc. - I won't create a Rails discussion here). Anyway, thank you for the tip. I've heard about Django, I'll take a look at it later. –  Sony Santos Sep 21 '11 at 19:31
    
All answers agree about using the Controller (or some BL tied to it), but I choose your answer due to the points on frameworks; the point 3 made me consider scaling issues. I don't know if I'll use one yet, but I'll think about. Thank you! –  Sony Santos Sep 22 '11 at 7:13
add comment

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.

share|improve this answer
2  
+1: or in a lot of cases handled in a class library but initiated by the controller. –  Joel Etherton Sep 21 '11 at 14:10
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.