0

Can someone point me in right direction with my question. I am interested either comprehensive articles and easily readable books about mvc-pattern and design patterns in general too.

Many people say that controller is just a "glue"(In every article double quotes seems to be very important part of explanation) between model and view. It does not tell too much about concept of controller it self.

My question is: Do you consider controller to be more model-specific or view-specific? and why?

In my current opinion they both have their own logic which can be wrapped in their own controllers. Other is just view specific controller and second is model specific controller.

Thanks in advance!

Ville
  • 464
  • 4
  • 14

2 Answers2

1

Views and controllers are considered to be part of the same layer in MVC architectural pattern. A correctly implemented MVC application has two layers: presentation layer and model layer.

The article with which you should begin is Folwer's "GUI Architectures". It should cover the basics.

Many people say that controller is just a "glue"(In every article double quotes seems to be very important part of explanation) between model and view.

Yeah, well ... they are wrong.

Controllers in MVC architecture are responsible for altering state of the model layer (and in few cases the current view, usually in desktop applications). In general, they do not receive any information back from model layer, thus - there is no "gluing" happening.

Note: there are implementations where controllers observe model layer, for altering how controller behaves, but that applies only to systems where model layers is persistent. For example: networked desktop application with two factor authentication - when user is authenticated, the existing controller starts interacting with different service from model layer.

You should take a look at the wiki page for MVC. Especially the diagram.

To answer your primary question:

Controllers are more view-specific, because user interactions with one specific UI (that has been produced by some view) will also be mostly handle by one specific controller.

Though, user's "signals" to a specific controller could be based on different UIs. For example, a REST API with json responses for listing all users VERSUS a HTML page with same user list - different view, same controller.

P.S.: unfortunately, it seems that your primary language is JS, for which I have no other post's that I could link to. Maybe except this answer. It would help you with understanding presentation layer, and you can ignore the "subjective bit" which contains PHP.

P.P.S: in MVC controllers do not contain application logic. Instead application logic should be contained in services, which are part of model layer.

Community
  • 1
  • 1
tereško
  • 58,060
  • 25
  • 98
  • 150
  • thanks a lot! As you see from other answers first sentence, this is definitely not a clear topic. I have had an understanding that every letter(m v and c) can be thinked as a one class. But i think it is not so simple, it is probably more like layers which might contain multiple classes(at least on model layer where actual models, handlers for data connections ,etc are needed), am i right? And contoller layer handles the connection to business logic and model-layer(and throws the answer to actual view)? – Ville Nov 22 '13 at 17:00
  • I would not refer to "controllers" as a layer. In my subjective opinions, for a group of classes to be considered a "layer", they have to be of various types but fulfilling the same general goal. And if you look at [this diagram](https://en.wikipedia.org/wiki/File:MVC-Process.svg) you will notice that the information does not flow throught-controller-to-view. Instead the view acquires it directly from model. And lastly, to see the explanation about model layer, see [this answer](http://stackoverflow.com/a/5864000/727208). It's too long for cramming into a comment. – tereško Nov 22 '13 at 18:29
-2

The controller should contain the business logic of your application and should not be aware (more than it needs to be) of either the model or the view. The idea being that it should be loosely coupled so that it can be reused (in other projects), the principle being the same as the Interface segregation principle of SOLID programming and the idea that the GUI will need to be updated or customized more often than the underlying model so decoupling the two keeps things easier to follow and organize.

This is what first introduced me to mvc: http://apcentral.collegeboard.com/apc/members/courses/teachers_corner/185168.html and it's explained pretty well IMO in a nice small package.

For the js approach to MVC have a look at https://developer.chrome.com/apps/app_frameworks

TigOldBitties
  • 1,331
  • 9
  • 15
  • how can a controller contain the business logic and also process the request, when you say that the principle standing is SRP? – jeremy Feb 04 '17 at 01:36
  • @jeremy Apparently you're confusing the mvc design pattern with the MVC framework. Did you at least look into the article provided? It's about the pattern and if you take the trouble to understand it, it's oversimplified into what i said. – TigOldBitties Feb 06 '17 at 13:34