Question

I’ve been seeing recently lots of “speculation” and small talk on this particular pattern (since I started to learn Dojo toolkit) but can’t find any clear info on that matter. Some say, it’s a solution to the frequently and “harmful” (they, not me) MVC pattern. I list some MVC “common” big picture problems solved by Interface-Compute. I found this site and read about it, but just can’t get the big picture about the pros/cons.

Input/Output

The view component is defined as a static component, never directly accepting input from the user. This is to say that reacting to user input is handled by a different component than presents user stimuli. But GUI programming environments do not draw a bright line between input and output components in this way: well-designed GUI programming environments are componentized into nested containers of user interface functionality.

Ignore Browser

If we consider web application frameworks that purport to support constructing so-called “rich internet applications”, the entire framework resides at the server, so, apparently both the view and controller are implemented at the server. This leaves the browser completely absent from the design model. If this is our mental picture of the design, then the browser is left to function as little more than a terminal with nice output capabilities.

etc…

I’m just wondering with all the JavaScript development like Dojo Toolkit, Node.js and some others for slick server side code (I think we might be going into this kind of era and rethink our ways of doing with server-side code with PHP, Java, Ruby on rails, etc.). Plus, it’s cool being able to debug both your server and client side code in your browser!

Answer 1

I had a quick read of the link you provided to find out the context of your quotes. I get the strong feeling the author has little knowledge of MVC and Object-Orientation.

The Model and View are collections/categories/domains of objects. Each object is completely self contained and should follow the OO principles. The Controller provides the View objects methods to interact with the Model objects (Because in general, an action alters many collaborating model objects, which can be complex).

A solution provided by Interface-Compute:

For example, if detecting a mouse click is implemented in a separate component than the component that presents a
pushed or unpushed button, then some non-trivial machinery must be constructed to communicate between the two
components when a mouse click occurs on a button. This problem disappears when mouse input recognition and button
presentation are implemented in the same component.

There are many benefits to implementing OO principles. Which seem to have been completely missed. So all I can say is that if he doesnt want to code with objects, MVC may not be suitable.