1

In my previous company which had an all-ajax web ap, there was a from-scratch framework being used. The way page sections refreshed was that you'd call the controller with a string, and the controller would load one or more view files. The view file would almost always call a class or classes in the model. This was as it was when I got there.

I am now working with a new company to develop a new system and looking at framework candidate. A 30 minute tutorial on codeigniter shows the controller calling the model, and the model loading the view.

This is opposite to what I am used to from my experience, so I wanted to ask which strategy is more common. In my mind it seems more rational that the view is a "shell" or structure but which is restricted to needing the model to get to the business rules.

I'm not sure if I should share a link here, I am NOT trying to promote codeigniter, but the tutorial is located at https://www.youtube.com/watch?v=47VOtKiw9AQ at about 10:00. Thanks

Oliver Williams
  • 5,966
  • 7
  • 36
  • 78
  • 3
    Last time I checked the view was used to display information and probably gather some information(to be passed to the controller). But the view should never directly call the model, or the controller for that matter. Separate your responsibilities. – Andrei P. Mar 02 '15 at 13:43
  • 2
    Agree with @AndreiP. The controller is the "central piece". It must be the one calling the model and loading the views. The only thing the model should call is the db. View never calls anything. [See what the doc say](http://www.codeigniter.com/userguide3/overview/mvc.html) – AdrienXL Mar 02 '15 at 13:51
  • For CodeIgniter, most common standard is, the controller is calling the model to retrieve data and then pass it to view. There should not be any direct connection between view and model. – Ariful Haque Mar 02 '15 at 13:52
  • @AndreiP. last place you checked was **completely wrong**. That's why CodeIgniter has nothing to do with MVC. Also, I would like to note that controllers should NOT be the "central piece". Instead they should be the tiniest part of the UI layer. – tereško Mar 02 '15 at 13:59
  • I agree with @tereško, and in fact yes our controller was "skinny". It would either call the view(s) which would call the model(s), or for updates just call a method in the view(s). But I never saw a case in our code where model(s) would call view(s) – Oliver Williams Mar 02 '15 at 14:15
  • @OliverWilliams it might have something to do with fact, that in CodeIgniter "views" are actually simple templates. In proper implementation the view instance would juggle multitude of templates. Kinda like described in [this post](http://stackoverflow.com/a/16596704/727208) ... but it not really a viable option in CI. – tereško Mar 02 '15 at 14:23
  • I just saw the video provided, around the 10 minute section which you pointed out, and I do not see anything being passed to the view from the model. Codeigniter's structure is not meant to do this. What he is actually doing in the video, is triggering his "index" method inside his "Site" Controller. This "index" method, loads the view (home.php view). He then goes on and explains how he can grab data from the model using his controller. Is there something I missed? – CodeGodie Mar 02 '15 at 15:08
  • @tereško, why do you say Codeigniter has nothing to do with MVC?? Is this just your personal opinion? From your point of view, how is the MVC structure suppose to be like? – CodeGodie Mar 02 '15 at 15:12
  • @CodeGodie, yes, at 10 minutes we're in a class Site which then does a ->load('viewname'). What I'm saying is, I've never seen that before. The structure I'm used to is, the view comes first, and references the model as necessary to get the data. Otherwise, with his tutorial, you are having to pass ALL your data to the view, which presumes you know more than the view does of what it needs - robbing it of its logical power - and in theory the view may have to reference the model AGAIN to get even more data if it needs to. To me, model->calling->view seems backward – Oliver Williams Mar 02 '15 at 15:15
  • 1
    I think youre getting confused. This class called `Site` in not your model. `Site` is your controller in this case. The controller is loading the view. If any data is needed, the controller would first gather that data from the model, and load it to the view. Perhaps the reason you are getting confused is because your old company's custom framework was designed to work more with ajax, which led you to think that the "view comes first". AJAX calls are actually coming from the view, but in this case it triggers controllers which then gather data and returns it to the view. – CodeGodie Mar 02 '15 at 15:21
  • @CodeGodie MVC is architectural pattern which puts constraints on information flow between application layers. It's not really anything that I can explain in 600 character limit. You might try going through materials [listed here](http://stackoverflow.com/a/16356866/727208). As for why CI has nothing to do with MVC .. well, it has no model layer, not views and "controllers" contain both application and presentation logic. It does not even adhere to the basics of [Separation of Constraints](http://en.wikipedia.org/wiki/Separation_of_concerns) principle. – tereško Mar 02 '15 at 15:24
  • @CodeGodie, you are correct. I was confused. When I saw a **class** named Site, I was confusing that with the Model. We never had controller classes, only model classes (usually one per db table). So yes, Site is the controller, and it is loading a view - not a "model" loading a view. – Oliver Williams Mar 02 '15 at 16:03
  • 1
    @tereško, thanks for the breakdown. I understand your point of view. CI does lack in many components and from an advanced developer's point of view i would agree.. However, I do believe that it is a good framework to start with, it provides a good transitioning in the deeper understanding of MVC in comparison to procedural coding. Which PHP frameworks do you recommend and why? – CodeGodie Mar 02 '15 at 16:19
  • @OliverWilliams, yes I thought that's what you meant. In addition, if you want to implement ajax in your app, you can still easily do this with CI. you would just simply need to call a controller when sending your ajax requests and let the controller do the work. – CodeGodie Mar 02 '15 at 16:21
  • @CodeGodie i'd say Laravel and Cake seem to be some of the best alternatives these days. – lhoppe Mar 04 '15 at 01:42

1 Answers1

0

tutorials. there are a lot of them.

controller calls the model and passes data to the view. thats the standard answer. however i'm now leaning towards - the controller assigns specific views, and then calls a template, passing $data.

and then in the template -- there are calls to a model to create the navigation bars for that template, and optionally a page display model.

otherwise -- either you have my_controller which everything passes through that could have calls to page display, navigation, etc.

Or you have to put page display details in every single controller. personally i'm not a big fan of the my_controller design pattern, and calls to a navbar in complex controllers are not optimal.

so in that case what might be considered a view -- a simple template file -- would be calling a model. but in this case its not really a "view" because its not displaying anything directly -- the template is calling the nav view, the header, the footer view, etc etc -- and then the actual page content is assigned by the controller.

this also gives you more portability - when you need to change details about the page display or navigation you only have to go to one place.

finally there's many php frameworks and many opinions. after a long dormant period the codeigniter framework is under active development. however if you are starting from square one take a look at Node as well, it has some compelling features depending on your use case.

cartalot
  • 3,147
  • 1
  • 16
  • 14