Is there something more behind MVC in web develop frameworks [closed]

Question

I just started my career in the web development about two months ago. During the two months, I wrote one web service in php Symfony2, get involed investigation of one project written in Python Flask and also help debugging a web service using Java Spring MVC.

OK, here is the summary.

• php Symfony2
• python Flask
• java Spring MVC

After getting a touch with these three frameworks, I've got to know that they are following the same pattern, MVC.

• Controller
  • one front controller to recieve requests from clients and transform those requests to calls to functions within controller objects which are wriitten by developers.
• View
  • after processing the requests, the framework uses the processing results to generate the pages that will be sent back the clients or just return some data to clients to response to ajax calls.
• Model
  • I have not quite got the idea of Model. Perhaps it is the way of handling database?

Questions:

1. Is this workflow that I wrote above a standard way of writing web services? If so, could you give me some useful links that contain the offcial documments?

2. or is it just a custom followed by developers? or just an industrial standard.

3. I think there are still some other factors behind the MVC pattern, like filters. (I haven't got the chance to use filters in my project, but I think there is more than filters behind the scene.)

4. I was told that these frameworks get ideas from ruby on rails which introduces this workflow. Is that true? where can I get the full introduction or documents about this kind of web services workflow?

Thanks very much.

Answer 1

You're asking a lot of questions here. Forgive me while I focus on clearing up just one thing.

Model View Controller is an architectural pattern that is not unique to web development. Anything with a user interface might make use of the MVC pattern. It's a pattern that organizes flow of control into a loop as seen here:

Each step is a level of indirection. The controller turns user input into manipulations of the model. The model turns those manipulations into updates to the view. The view turns those updates into something the user can see. The user turns what they see into user input. And so on.

Each step is also an abstraction. The model may be implemented as a database, data structure, file, etc. The model should abstract much of this detail away with a simple API for changing it's state. That way a change, from say file to database, wouldn't affect any code besides model code.

The controller may take input from a mouse, keyboard, touch screen, voice recognition, etc. The controller should abstract much of that detail away by transforming it into requests to manipulate the state of the model. That way a change from, say mouse to touch screen, wouldn't affect any code besides the controller code.

The view takes the representation of the model (which might be numbers or such) and presents it as something the user can see (which might be a GUI or a pie chart or such). There might be multiple views that each represent a way to present the model.

MVC is a very old pattern and has been implemented in many different ways, for example:

https://developer.chrome.com/apps/app_frameworks

Here the flow has changed drastically but each component should still have the same basic responsibilities and protect the others from changes.

I'm trying to take it back to basics. THIS is what MVC really is. There are a great many things that use it that add plenty of bells and whistles but the indirection and abstraction are what I think of as the "something more" behind MVC.