MVC: why do we need "controller", or when should we use this pattern?

Question

I have read many publications about MVC, but I still can't clearly understand why do we need "controller".

I usually write applications in client-server model:

server contains all the business-logic, and it knows nothing about the gui. It does the main job, and it is as portable as possible.

client is a GUI, it binds to the server, interacts with user, sends commands from user to the server.

I like this architecture, and I can't figure out why do people really need one more medium between client and server, which seem to be controller?

UPD: simple example: assume we need to write some data logger. Data comes from the COM port, it is encoded by some protocol. Need to show received messages in a simple log window.

How would I make it:

server contains the following items:

• Data_receiver: actually receives raw data from the COM port, but it's interface, so we are able to make some another class that receives data from any other source;
• Data_decoder: takes raw data and returns resulting decoded messages, it's interface too, so we can change encoding protocol easily;
• Data_core: using instances of Data_receiver and Data_decoder, emits signals to clients.

client contains the following items:

• Appl core: creates instance of Data_receiver (the one that connects to COM port), Data_decoder and Data_core (which takes references to Data_receiver and Data_decoder instances), also creates GUI simple log window (which takes reference to Data_core);
• GUI simple log window: binds to the Data_core, i.e. listens for the signals emitted by it, and displays received data.

As I understood what I have read about MVC, GUI should not actually take received messages from the Data_core, because controller should do that and then pass data to the GUI. But what bad things happens if GUI takes this data directly from the model?

Answer 1

In the past I have asked myself this same question many times and I have recently been reading about JSP model 2 architecture, and the wikipedia entry states the following.

The literature on Web-tier technology in the J2EE platform frequently uses the terms "Model 1" and "Model 2" without explanation. This terminology stems from early drafts of the JSP specification, which described two basic usage patterns for JSP pages. While the terms have disappeared from the specification document, they remain in common use. Model 1 and Model 2 simply refer to the absence or presence (respectively) of a controller servlet that dispatches requests from the client tier and selects views.

That basically means that there are variations to the MVC pattern itself so you can always apply a MVC or MV pattern depending on your project. However a proper MVC architecture should indeed have a controller as the model and view should not talk to each other directly.

Answer 2

"client-server" has nothing to do with MVC, afaik.

I understand it like this:

• The Model is the way you structure your data.
• The View is the visible representation. (GUI)
• The Controller uses the logic to control the view and/or other logic.

The idea behind it is to split the visual representation from the logic. So when you grab the View you dont duplicate the logic. ... so in your case you might use MVC only on the client side and you need a controller, because thats where all the magic happens.