Is ASP.NET MVC is really MVC? Or how to separate model from controller?

Question

Hi all,

This question is a bit rhetorical. At some point i got a feeling that ASP.NET MVC is not that authentic implementation of MVC pattern. Or i didn't understood it.

Consider following domain: electric bulb, switch and motion detector. They are connected together and when you enter the room motion detector switches on the bulb. If i want to represent them as MVC:

• switch is model, because it holds the state and contains logic
• bulb is view, because it presents the state of model to human
• motion detector is controller, because it converts user actions to generic model commands

Switch has one private field (On/Off) as a State and two methods (PressOn, PressOff). If you call PressOn when it is Off it goes to On, if you call it again state doesn't change.

Bulb can be replaced with buzzer, motion detector with timer or button, but the model still represent the same logic. Eventually system will have same behavior.

This is how i understand classical MVC decomposition, please correct me if i am wrong.

Now let's decompose it in ASP.Net MVC way.

• Bulb is still a view
• Controller will be switch + motion detector
• Model is some object that will just pass state to bulb.

So the logic that defines behavior moves to controller.

Question 1: Is my understanding of MVC and ASP.NET MVC correct?
Question 2: If yes, do you agree that ASP.NET MVC is not 100% accurate implementation?

And back to life. The final question is how to separate model from controller in case of ASP.NET MVC. There can be two extremes. Controller does basic stuff and call model to do all the logic. Another is controller does all the logic and model is just something like class with properties that is mapped to DB.

Question 3: Where should i draw the line between this extremes? How to balance?

Thanks, Andrey

Answer 1

I think it could be either way. Here would be an implementation is ASP.NET MVC that keeps the logic like you had in your first example.

Model (Respository)

Function switchOn() as bulb
    if !bulb.lightOn then
        bulb.lightOn = true
    end if
        return bulb
End Function

Function switchOff() as bulb
    if bulb.lightOn then
        bulb.lightOn = false
    end if
        return bulb
End Function

Function Motion(senseMotion as boolean) as bulb
    if(senseMotion and !bulb.lightOn) then
         bulb.lightOn = true
    end if
    return bulb
End Function

Controller

Function PressSwitchOn() as actionresult
     return view("Bulb", lightRepository.switchOn)
End Function

Function PressSwitchOff() as actionresult
     return view("Bulb", lightRepository.switchOff)
End Function

Function SomethingMoved(byval hasMoved as boolean) as actionresult
     return view("Bulb", lightRepository.Motion(hasMoved))
End Function

No business logic in my controller, it is simply passing the state from the model to the view. Am I in the ballpark of your example?

To answer questions.

1. Yes, I think you understand it pretty well
2. No, I would disagree. One of the benefits of ASP.NET MVC is that it is extremely flexible in your implementation. You could put all of your logic in your view if you really wanted to (why, oh why would someone want to do that), but you have the option.
3. I think to draw the lines, keep the DRY principles in mind. If you have logic repeated multiple times, make sure its part of the model or some custom business class that you can reference from one place. That to me is one of the main driving principles of designing a MVC app.

Answer 2

In your example, the motion detector still has to call SwitchOn and SwitchOff, which is basically the same as a controller calling the same methods on a repository. So if you consider an ASP.NET MVC application implementing the repository pattern, your argument falls.

Conclusion:

1. Yes, in principle you are correct, but you are being very limited in how the MVC framework can be used.
2. No, I don't agree with you.
3. Is it important? MVC is a pattern designed to make developing easier - not harder. Write your application in a way that feels relevant, and call it "MVC inpsired" if you think you're breaking the rules (but who the heck would care...?).