-1

I'm going for an example to make the question easier: If you are implementing facebook, you want to separate user information from account information, from posts, from from from, that means there will be a model for user, a model for user info, a model for posts, a model for for for.

now if you go to user profile, it loads information from all these models, the question is how would you structure the controllers, of course you need controllers for each model to define it's unique actions, but how do i handle the rendering? do i make a new controller that takes care of all renderings? or do i just put render profile in the user controller - which means it will have access to other models - or do i put in each controller a rendering of it's own and then combine them together... or maybe if you have a better approach?

i just do not know the consequences of each approach that i thought of, and i don't know if there is a better approach that i didn't think of.

tereško
  • 58,060
  • 25
  • 98
  • 150
UX Labs
  • 1,481
  • 14
  • 29
  • You don't need a controller for each model. Controllers implement methods that to which routes are mapped and all logic is handled inside Models. You can have models that simply represent a table/model relation. Also your question is way to broad. You handle rendering by appropriate view class using some layout manager which all 4 frameworks that you tagged have. You can have controllers render partial views that extend a layout view. – Sterling Duchess Feb 25 '14 at 17:29

3 Answers3

1

of course you need controllers for each model to define it's unique actions

No, this is wrong.

Controllers are part of your presentation layer, some might say you need a controller for each view object which is okay but for the model layer, it has nothing to do with the number of controllers you have.

a View is an object that toggles multiple templates and once again this has nothing to do with your controller, rendering is a view responsibility. to understand it more, take a look here , here and here

those are really useful information to start with.

Community
  • 1
  • 1
mamdouh alramadan
  • 8,349
  • 6
  • 36
  • 53
  • my problem is that i cannot easily understand without examples, i've seen many sources that try explain the concepts, and even the provided sources are causing me the same headache, when i know for sure if someone just provided me the names of the controllers which i would use, then i would start catching the concept. – UX Labs Feb 25 '14 at 18:04
  • what do you mean by `the names of the controllers which I would use` – mamdouh alramadan Feb 25 '14 at 18:20
1

As others mentioned, you don't need a controller specifically for each model. However, given your Facebook example, it's quite simply done through relationships.

An oversimplification would be:

A User model to hold the user's account information and relationships

class User extends Eloquent {
    public function posts() {
      return $this->hasMany('posts', 'from_user_id');
    }
}

A Post model to hold the content and from/to relationships to User

class Post extends Eloquent {
    public function from() {
      return $this->belongsTo('user', 'from_user_id'); 
    }

    public function to() {
      return $this->belongsTo('user', 'to_user_id');
    }
}

Then perhaps you'd have UserController load a view like so:

class UserController extends BaseController {
  public function index($id) {
    $user = User::find($id);
    return View::make('user_page', array(
      'user' => $user, 
      'posts' => $user->posts()->with('to')->get()
    ));        
  }
}
TonyArra
  • 10,607
  • 1
  • 30
  • 46
0

Wrong answer - controllers are not part of presentation layer - they are part of transport layer. Their task is to react on HTTP request. Request is dispatched by Router. To proof take a look at Laravel source. Controller is a part of Routing package. When you call for example:

Route::get("/","HomeController");

You are just registering request parameters in RouteCollection. But everything is happening inside Router. Controllers can exist without any kind of view layer.

Miroslav Trninic
  • 3,327
  • 4
  • 28
  • 51
  • first this is a comment not an answer, second, you are confusing controllers with routers!!! – mamdouh alramadan Feb 25 '14 at 18:26
  • check [this explanation](http://stackoverflow.com/questions/12429729/controller-belongs-to-the-presentation-layer) so you might get it after reading it. – mamdouh alramadan Feb 25 '14 at 18:44
  • hehe Java is not PHP if you didn't know. Have you look at Laravel source ? – Miroslav Trninic Feb 25 '14 at 18:48
  • 1
    there is no MVC design in PHP, Laravel is not MVC – mamdouh alramadan Feb 25 '14 at 18:49
  • My 2 cents: Laravel could be 100% functional without Controllers, as controller-type functions can be defined within routes. A controller's job in Laravel is to 1) decide what data gets returned to the user via a View or HTTP Response; 2) logically organize your route actions; 3) modify/create models and format model data for use in the view; 4) dependency injection – TonyArra Feb 25 '14 at 20:44
  • finally someone who understands :) – Miroslav Trninic Feb 25 '14 at 21:02
  • (edited) Laravel is in fact MVC for one thing. Secondly, I don't think that "transport layer" in OSI applies here, as Laravel is not a network protocol. The "presentation layer" being referred to by mamdouh is part of a "multilayered architecture"; in which Models could be considered the "data-access layer" and Views the "presentation layer". Controllers are usually considered their own layer called the "controller layer" http://en.wikipedia.org/wiki/Multilayered_architecture – TonyArra Feb 25 '14 at 21:29
  • This is also relevant: http://stackoverflow.com/questions/12429729/controller-belongs-to-the-presentation-layer – TonyArra Feb 25 '14 at 21:39