Every computer science major and their iguanas have heard of the MVC pattern. It's being used by everyone from Sun to Microsoft.
Here's a diagram showing how MVC is suppose to work (shamelessly copied from wikipedia)
Now quoting from Wikipedia's entry on MVC [http://en.wikipedia.org/wiki/Model-view-controller] "Successful use of the pattern (i.e. MVC) isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other."
Now here's what Reenskaug has to say about MVC (BTW, Trygve M. H. Reenskaug is the inventor of MVC) [http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html] and I quote "The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer. The ideal MVC solution supports the user illusion of seeing and manipulating the domain information directly. The structure is useful if the user needs to see the same model element simultaneously in different contexts and/or from different viewpoints."
Wait a minute, that's different: The inventor of MVC emphasises the ability of MVC to give different views of the same data, while the wikipedia entry somehow talks about isolating (i.e. modularising - is there such a word?) application. Those two things are not the same!
The rub is, if you allow me to repeate: MVC was not created to modularise application, repeate after me. It was not for isolation people! It was created to give different views of the same big gianourmous data (c.f. Reenskaug's definition).
Sure, things are seperated into model, view and controller but that is just a consequences and not the main goal of MVC.
Confusing the goal of MVC with some other goals is actually detrimental to software development. Let us see how.
A typical MVC flow is like this:
User input --> Controller --> Update model--> View, observing the model has changed, updates itself
A typical non-MVC flow would be like this:
User input --> Controller --> (Update model and Update view)
The non-MVC is the model followed by say a typical Java Swing application, JSF and Struts. The problem is that the view is really inactive. The vision of multiple views being in sync with the huge data in the back-end becomes more difficult. Say, for example I want to add a new field in the view. The field already exist in the database, just a matter of displaying it. With MVC, I just query the model (from the view) when the view is "waken up" by the observation event. I need to change the view and that's that. With non-MVC approach, I have to update both the view and the controller to get the same effect.
The problem lies in the fact that, even in the non-MVC approach, my code is isolated and compartmentalised, if I stick with the definition given by wikipedia, I would therefore have the impression of doing MVC without actually doing it. Whereas with MVC, I'm reaping the benefit of MVC and at the same time getting my modularity, its like having my cake and eat it too.
Given how fast interface technology (RIA, Flex, JavaFX, Silverlight, your-hoot-n-nanny-of-the-day) is evolving, having multiple, insync views of a large data is inevitable. You would probably need to cater for, at least, the web and the mobile audience. Having a real MVC framework would help enormously... if and only if MVC is done correctly.
Here's a diagram showing how MVC is suppose to work (shamelessly copied from wikipedia)
Now quoting from Wikipedia's entry on MVC [http://en.wikipedia.org/wiki/Model-view-controller] "Successful use of the pattern (i.e. MVC) isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other."
Now here's what Reenskaug has to say about MVC (BTW, Trygve M. H. Reenskaug is the inventor of MVC) [http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html] and I quote "The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer. The ideal MVC solution supports the user illusion of seeing and manipulating the domain information directly. The structure is useful if the user needs to see the same model element simultaneously in different contexts and/or from different viewpoints."
Wait a minute, that's different: The inventor of MVC emphasises the ability of MVC to give different views of the same data, while the wikipedia entry somehow talks about isolating (i.e. modularising - is there such a word?) application. Those two things are not the same!
The rub is, if you allow me to repeate: MVC was not created to modularise application, repeate after me. It was not for isolation people! It was created to give different views of the same big gianourmous data (c.f. Reenskaug's definition).
Sure, things are seperated into model, view and controller but that is just a consequences and not the main goal of MVC.
Confusing the goal of MVC with some other goals is actually detrimental to software development. Let us see how.
A typical MVC flow is like this:
User input --> Controller --> Update model--> View, observing the model has changed, updates itself
A typical non-MVC flow would be like this:
User input --> Controller --> (Update model and Update view)
The non-MVC is the model followed by say a typical Java Swing application, JSF and Struts. The problem is that the view is really inactive. The vision of multiple views being in sync with the huge data in the back-end becomes more difficult. Say, for example I want to add a new field in the view. The field already exist in the database, just a matter of displaying it. With MVC, I just query the model (from the view) when the view is "waken up" by the observation event. I need to change the view and that's that. With non-MVC approach, I have to update both the view and the controller to get the same effect.
The problem lies in the fact that, even in the non-MVC approach, my code is isolated and compartmentalised, if I stick with the definition given by wikipedia, I would therefore have the impression of doing MVC without actually doing it. Whereas with MVC, I'm reaping the benefit of MVC and at the same time getting my modularity, its like having my cake and eat it too.
Given how fast interface technology (RIA, Flex, JavaFX, Silverlight, your-hoot-n-nanny-of-the-day) is evolving, having multiple, insync views of a large data is inevitable. You would probably need to cater for, at least, the web and the mobile audience. Having a real MVC framework would help enormously... if and only if MVC is done correctly.
No comments:
Post a Comment