"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.

where to put logic

examples

Larvel docs

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.

where to put logic

examples

Larvel docs

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.