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 ofData_receiver
andData_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
andData_core
(which takes references toData_receiver
andData_decoder
instances), also creates GUI simple log window (which takes reference toData_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?