Search code examples
model-view-controllerlaravel-5cakephp-3.0solid-principles

How to properly setup a MVC application like CakePHP and Laravel?


I'm trying to understand the benefits of fat models and skinny controllers notion. I've read many articles so far and below are my questions. Please answer the questions considering what's the best approach in CakePHP 3 and laravel 5.2.

1) Does following fat models/keeping the business logic inside controllers notion simply means never to use the ORM methods like find, save, etc inside the controllers.

2) Why do all the examples in cakephp and laravel documentation show queries inside controllers only and not inside the custom model functions which should be called in controllers.

3) There are many patterns and architectures like datamapper, repository, active record. Which one is best for a large scale enterprise applications. Is it better to go with Doctrine in such case rather than the bundled ORM's ?

4) What if i need to call another model inside a custom model function. Is that okay? if not then what should be the best approach in such case. Please explain with an example like cakephp doc uses blog,user, comments, etc

Thanks.


Solution

  • You're asking some pretty broad questions here so expect broad answers. To give you some insight from my experiences:

    1. No, there are many cases where the logic is simple enough or not directly bound to data that the business logic can be contained in a controller method. That being said, I like to treat controllers as the roadway between two endpoints; i.e. i may pick up data along the way but I try not to manipulate data in a controller, merely serve it to a view or to a repository to be updated.
    2. Simplicity? It's best not to introduce too many concepts into one example. The same principle applies to programming, abstract and keep things simple.
    3. I've used the repository pattern, active record and doctrine all in projects. It's the right tool for the right job.
    4. I try to keep direct model access as abstracted as possible. Your underlying storage schema may change at any point and it's best not to rely on any sort of "structure" being there.