It seems everyone doing web applications nowadays wants to use MVC for everything. I find it hard to convince myself to use this pattern, however. I understand the general idea is to separate the backend logic from the frontend that represents the program. Generally, it seems that the views always depend on the controller to some extent, which ends up depending on the model. I don't see what advantage adding the controller gets me. I've read a lot of hype about "this is the way applications should be designed", but maybe I still don't understand what is supposed to go where. Whenever I talk to others about MVC it seems everyone has a different idea of what belongs in what category.

So, why should I use MVC? What do I gain by using MVC over just separating the frontend from the backend logic? (Most "advantages" I see of this pattern are gained just by separating interface from implementation, and fail to explain the purpose of having a separate "controller")

Heh. Martin Fowler agrees with your confusion about MVC:


  I don't find it terribly useful to think of MVC as a pattern because
  it contains quite a few different ideas. Different people reading
  about MVC in different places take different ideas from it and
  describe these as 'MVC'. If this doesn't cause enough confusion you
  then get the effect of misunderstandings of MVC that develop through a
  system of Chinese whispers.


However, he goes on to give one of the more cogent explanations of what motivates MVC:


  At the heart of MVC is what I call Separated Presentation. The idea
  behind Separated Presentation is to make a clear division between
  domain objects that model our perception of the real world, and
  presentation objects that are the GUI elements we see on the screen.
  Domain objects should be completely self contained and work without
  reference to the presentation, they should also be able to support
  multiple presentations, possibly simultaneously.


You can read Fowler's entire article here.
