Hi,
I've just started porting my vanilla PHP gastropod simulation project to Laravel and had some questions about how my current class structure could fit into the framework's MVC pattern.
Basically, in the vanilla PHP version I have pages, main object classes, and manager object classes. Two examples:
-
snail.php
-
snail.class.php
-
snailmanager.class.php
-
jar.php
-
jar.class.php
-
jarmanager.class.php
I should note that snail data is not limited to being displayed on snail.php - snails are also instantiated and displayed on jar.php, for example.
Currently, in the no-framework version, I've been structuring every main object class (ie snail.class.php) in a way that ensures the class only contains methods that pertain to a specific instance of an object. So you'd never see a method like findSnailsByJarID() in snail.class.php because it would often return more than one snail. Instead, those sorts of things - methods that require pulling out multiple snails based on given requirements or trigger any sort of events on a set of snails/jars/whatever would go into snailmanager.class.php, jarmanager.class.php, etc.
An example of stuff in snail.class.php would be: updateSnail, loadSnailInfo, generateNewbornSnail, generateGeneString, depleteEnergy, etc.
An example of stuff in snailmanager.class.php would be: findSnailsByJarID, nightlyEnergyDepletion (which would call depleteEnergy for each relevant snail), etc.
The question
My question is - how should I split this up in an MVC pattern as pertaining to Laravel? Where should the logic pertaining to each instance of an object go? Some people have suggested putting everything into the controller, others in the model. Most seem to suggest not separating methods that affect one instance of an object from methods that perform actions on multiple objects (so there would be no separation such as the one I had with snail.class.php and snailmanager.class.php). Should they all just sit together in the model and/or controller? I'm reading up on MVC in general but it would be great to get some advice specific to Laravel.
Thanks!
"How should I split this up in an MVC pattern as pertaining to Laravel?"
I would keep my models fat and controllers thin. This is the biggest mistake most developers make. The controller just points the data holds some conditionals. Validation using business logic should be used in the model although I do not always do this.
Everything that relates to an object should be in its own controller. This makes it easier to re-use code for other projects and keeps an ORM. So the model relates to the database which both in turn work with the corresponding controller.
Laravel has ways for the logic to all work together and keep organized. You can help keep your logic together by using controller routes or RESTFUL Controllers.
Personally I am used to using routes and passing an array.
Also, if you want to separate say access from a back-end cms to the front-end you would use Auth checks and restrict access based on permissions in the database such as a boolean.
I am sure you could also extend the controllers, so you would set up an admin controller and a public controller.
It sounds like you have snails and then want to manage the snails. So I would easily separate it by just having an admin directory and giving access to only admin of that directory. I would also have a controller separate for managing the snails.
Some one else can elaborate on this.
swgj19 said:
"How should I split this up in an MVC pattern as pertaining to Laravel?"
I would keep my models fat and controllers thin. This is the biggest mistake most developers make. The controller just points the data holds some conditionals. Validation using business logic should be used in the model although I do not always do this.
Everything that relates to an object should be in its own controller. This makes it easier to re-use code for other projects and keeps an ORM. So the model relates to the database which both in turn work with the corresponding controller.
Laravel has ways for the logic to all work together and keep organized. You can help keep your logic together by using controller routes or RESTFUL Controllers.
Personally I am used to using routes and passing an array.
Also, if you want to separate say access from a back-end cms to the front-end you would use Auth checks and restrict access based on permissions in the database such as a boolean.
I am sure you could also extend the controllers, so you would set up an admin controller and a public controller.
It sounds like you have snails and then want to manage the snails. So I would easily separate it by just having an admin directory and giving access to only admin of that directory. I would also have a controller separate for managing the snails.
Some one else can elaborate on this.
Thank you, this helps. I still have a lot of thinking to do, but at least I know the general vicinity of the right track.
If I'm reading your structure properly I'd say
- snail.php -> controller
- snail.class.php -> Model
- snailmanager.class.php -> Model
- jar.php -> controller
- jar.class.php -> Model
- jarmanager.class.php -> Model
Your models don't need to map directly to the view | controllers | models directory structure. Often it is a good idea to create a namespace for all your domain logic.
I suggest a directory structor of:
- snail.php -> Controllers/SnailController.php
- snail.class.php -> Gastropod/Entities/Snail.php
- snailmanager.class.php -> Gastropod/Managers/SnailManager.php
- jar.php -> Controllers/SnailController.php
- jar.class.php -> Gastropod/Entities/Jar.php
- jarmanager.class.php -> Gastropod/Managers/JarManager.php
Any domain logic can go in your ~/app/Gastropod namespace and anything application special (HTTP layer) can stay in ~/app e.g. Controllers, Composers, Views
Thanks, damien.
Hmm, I think that snail.php and jar.php are closer to views than controllers. This is where all the templating and rendering is actually done and a large part of them is plain old HTML.
Before I saw your post I started hacking together a kind of similar system to what I have now, though with the expectation of revising it as I learn more. Right now I basically have Controllers doing largely what Managers did in the vanilla PHP version. I wrote a blog post about it that I'll link below, but the general gist has been this:
- /models/Jar.php
- /controllers/JarController.php
- /views/stable/jar.php
Then necessary data for the Jar page is retrieved via a View Composer, which calls functions in necessary controllers to get information about the jar, the snails within it, and the user that owns it.
The full post is here: http://liza.io/experimenting-with-laravel/ (It largely uses this question to explain my confusion and then has a brief description of the current Laravel implementation at the end)
However, the method you described makes sense also (and is likely a much better idea than my makeshift current version), so I will think about this option and maybe try implementing something like what you describe when I've fully gotten my head around it.
Thanks again!
Good to know. Good luck. Feel free to ask more questions.
Sign in to participate in this thread!
Laravel
Laravel News
Laracasts
Laravel Podcast