I’m new to cakephp, and for that matter the mvc concept as well, tough learning curve!!!
anyways, I am confused about the fat model idea.
The tutorials of cake set the save and retrieve functions for models in the controllers,
and so have I started doing…
but quickly, i have to call other controllers functions from within controllers
// within YourController
$x= new MyController();
$y= $x->action1();
I need to save associated data with some models, and be able to retrieve it as well
for now, the
->newEntity()
_prepare
->dispatchEntity($a,$b,[ ‘associated’ =>
table1
table1.table2
table1.table3.table3
)
->save
is in one controller, but it feels like calling controllers from within others is not right,
and from what I understand, the datawork should be in the model(table?entity?)
should I put the data manipulation in the model? if so, how do I deal with the associations?
and why are the tutorials dealing with the data in the controllers?
your help is much appreciated !
thanks in advance,
Tibo
The thin controllers, fat models principle is an ideal and not always sensible.
Basically, you can do almost everything in the controller (apart from maybe validation and a few other things), but a division of concerns can be extremely helpful in making it easier to work with your app.
That’s why you should try to put the low-level data preparation logic into the models and have the controllers deal with higher level functionality.
It’s just that quite often, it’s much simpler to write $this->Articles->get($id) in the controller than create a dedicated model method just for that purpose… Hence you will see a lot of tutorials that don’t really follow the fat models principle, simply because it’s not practical for simpler applications. It will get more useful the more complex your code gets.
Also, if you want to access data from a model that’s not directly related to the current controller, you should set up some kind of relationship. You can access distant relatives quite easily like $this->Articles->Notices->Users->findSomething() etc.
That’s why you should try to put the low-level data preparation logic into the models and have the controllers deal with higher level functionality.
Maybe is the idea you want to transmit, but I would remark that the functionality in the controllers should be only authentication stuff and setting up the response, not much more than that. And the model, in Cake jargon, should only manipulate data. Everything else should go in a domain layer that is the real deal of the application.
One of the more misleading things with PHP MVC frameworks is that their documentation kind of encourage overskilled controllers. Cake is specially “good” at this.
That’s very interesting, and yes, most MVC frameworks do seem to encourage putting most of the business logic inside of the controller. So do I understand you correctly if you propose to basically create custom classes in /src for the actual “meat” of the application? Could you expand on that and / or provide resources, because I think it’s very useful but there doesn’t seem to be much info on that approach, at least in the CakePHP world.
I agree,
I have juste started with cake, and I’m having a extremely hard time finding examples outside the cookbook, which is nicely presented, touches a little bit on everything, yes not enough for one to be independant…
I would LOVE if there were some diagrams in the cookbook for instance, showing examples of all the various classes… and of what Cake actually does with them.
The baked controllers are not intuitive at all eg: it took me while to get that in the typical add() function in the controller, it was going towards AND back from the controller to the view public function add() { $linkedinProfile = $this->LinkedinProfiles->newEntity(); if ($this->request->is('post')) { $linkedinProfile = $this->LinkedinProfiles->patchEntity($linkedinProfile, $this->request->data); if ($this->LinkedinProfiles->save($linkedinProfile)) { $this->Flash->success(__('The linkedin profile has been saved.')); return $this->redirect(['action' => 'index']); } else { $this->Flash->error(__('The linkedin profile could not be saved. Please, try again.')); } } $users = $this->LinkedinProfiles->Users->find('list', ['limit' => 200]); $this->set(compact('linkedinProfile', 'users')); $this->set('_serialize', ['linkedinProfile']); }
it seems obvious now, … but it wasn’t …
the same for template, view, blocks, elements, layout, plugins, themes
looks simple in the cookbook until you try it.
and the business logic … where do I put it? component, behavior, controller, entity, table
at the moment, since I want to use bootstrap, I’m trying to use twbs-cake-lugin … my head is heating up !!!
any example of a working app with a bit of everything would be of great help, I guess !!!
Accessing the ORM directly form the controllers, like is suggested all around the doc and examples, is really cool for RAD but, in my opinion, not a good idea for more than a prototype or a very simple application. It kind enforces you to put business logic into Table classes, which I think (I insist, personal opinion here) is not a good approach. Table classes should speak with the database and nothing more than that.
Of course it’s up to you to use this “controller talking directly to tables” flow, but is hard to don’t go that way if the documentation uses it all around and the controllers are using the ModelAware trait by default. Anyway, seems to be the cakish way and is something optional at the end.
Some resources about using your MVS framework as part of the outer layers of your application:
The videos are advanced stuff for newbies getting into the framework world for the first time. Also they use Symfony for examples, but are pretty understandable.
