I'm familiar with OOP and PHP, but I'm new to MVC frameworks. I'm currently using Laravel and have found it wonderful so far, but things have gotten trickier as I've progressed, and now I realise I need to rethink my architecture.

The project is a digital assets manager for a small client, but I still want to make sure I'm developing it as well as I can, despite its size.

The basic object relationships are:

• A CLIENT can have many PROJECTS.
• A PROJECT can have many SECTIONS.
• A SECTION can have many ASSETS.

Seems simple enough, right?

I have a CLIENT and PROJECT all working fine, using RESTful, but I'm unsure how to deal with the SECTIONS and ASSETS. There are 6 types of sections that a project can have ONE of: Eg. Photos, External Links, About, Videos, etc. There is also a 7th section that a project can have many of (a free-for-all, essentially).

Each of the sections contains one or more asset. For example an About section can only contain one body of text, but a Photos section could contain many photos.

Ideas for approach

If I was writing this using vanilla PHP, I'd probably have an Asset object and then have Photo, About, External Link, that Extended Asset.

The more I've thought about it, the more I've questioned if I even need a Section object, too.

Given that I'm using MVC, I'm not sure whether I should have a different Controller and Model for each Asset type, or if that's overkill. Maybe I should just have an Asset Model (and one Asset Controller), and then have more Models for each of the Asset types that Extends that Model.

I also contemplated having one big Assets table to store them all. Yes, that would have a ton of empty cells, but it wouldn't be a problem in a practical sense, given the small size of the project. (Premature optimization and all that.)

Maybe I'm overthinking it. Maybe I've not thought about it enough. Maybe I'm just not seeing that it's really obvious that I should create lots of different Controllers.

Any assistance to help shape my thinking toward a good use of MVC would be greatly appreciated.

Update: Further thoughts

Having had more time to ruminate, learning more about MVC and think about comments made by @RobertHarvey, I've started thinking more about the Models I've chosen. I come to think that's really where this question (and its solution) lies.

I've started building the site with a model for each SECTION type and ASSET type (eg. VideoSection and VideoAsset are two models I have now.

A Project can have one VideoSection. A VideoSection can have many VideoAssets. Fingers crossed this is a good way to approach this.

I'm familiar with OOP and PHP, but I'm new to MVC frameworks. I'm currently using Laravel and have found it wonderful so far, but things have gotten trickier as I've progressed, and now I realise I need to rethink my architecture.

The project is a digital assets manager for a small client, but I still want to make sure I'm developing it as well as I can, despite its size.

The basic object relationships are:

• A PROJECT can have many SECTIONS.
• A SECTION can have many ASSETS.

Seems simple enough, right?

I have PROJECT working fine, using REST, but I'm unsure how to deal with the SECTIONS and ASSETS. 

There are 6 types of sections that a project can have ONE of: Eg. Photos, External Links, About, Videos, etc.

Some of the sections contains one or more asset. For example an About section can only contain one body of text, but a Photos section could contain many photos. Each type of asset has a different set of properties.

Ideas for approach

If I was writing this using vanilla PHP, I'd probably have an Asset object and then have Photo, About, External Link, that Extended Asset.

The more I've thought about it, the more I've questioned if I even need a Section object, too.

Given that I'm using MVC, I'm not sure whether I should have a different Controller and Model for each Asset type, or if that's overkill. Maybe I should just have an Asset Model (and one Asset Controller), and then have more Models for each of the Asset types that Extends that Model.

Any assistance to help shape my thinking toward a good use of MVC would be greatly appreciated.

Update: Further thoughts

Having had more time to ruminate, learning more about MVC and think about comments made by @RobertHarvey, I've started thinking more about the Models I've chosen. I come to think that's really where this question (and its solution) lies.

I've started building the site with a model for each SECTION type and ASSET type (eg. VideoSection and VideoAsset are two models I have now.

A Project can have one VideoSection. A VideoSection can have many VideoAssets. Fingers crossed this is a good way to approach this.

I'm familiar with OOP and PHP, but I'm new to MVC frameworks. I'm currently using Laravel and have found it wonderful so far, but things have gotten trickier as I've progressed, and now I realise I need to rethink my architecture.

The project is a digital assets manager for a small client, but I still want to make sure I'm developing it as well as I can, despite its size.

The basic object relationships are:

• A CLIENT can have many PROJECTS.
• A PROJECT can have many SECTIONS.
• A SECTION can have many ASSETS.

Seems simple enough, right?

I have a CLIENT and PROJECT all working fine, using RESTful, but I'm unsure how to deal with the SECTIONS and ASSETS. There are 6 types of sections that a project can have ONE of: Eg. Photos, External Links, About, Videos, etc. There is also a 7th section that a project can have many of (a free-for-all, essentially).

Each of the sections contains one or more asset. For example an About section can only contain one body of text, but a Photos section could contain many photos.

Ideas for approach

If I was writing this using vanilla PHP, I'd probably have an Asset object and then have Photo, About, External Link, that Extended Asset.

The more I've thought about it, the more I've questioned if I even need a Section object, too.

Given that I'm using MVC, I'm not sure whether I should have a different Controller and Model for each Asset type, or if that's overkill. Maybe I should just have an Asset Model (and one Asset Controller), and then have more Models for each of the Asset types that Extends that Model.

I also contemplated having one big Assets table to store them all. Yes, that would have a ton of empty cells, but it wouldn't be a problem in a practical sense, given the small size of the project. (Premature optimization and all that.)

Maybe I'm overthinking it. Maybe I've not thought about it enough. Maybe I'm just not seeing that it's really obvious that I should create lots of different Controllers.

Any assistance to help shape my thinking toward a good use of MVC would be greatly appreciated.

I'm familiar with OOP and PHP, but I'm new to MVC frameworks. I'm currently using Laravel and have found it wonderful so far, but things have gotten trickier as I've progressed, and now I realise I need to rethink my architecture.

The project is a digital assets manager for a small client, but I still want to make sure I'm developing it as well as I can, despite its size.

The basic object relationships are:

• A CLIENT can have many PROJECTS.
• A PROJECT can have many SECTIONS.
• A SECTION can have many ASSETS.

Seems simple enough, right?

I have a CLIENT and PROJECT all working fine, using RESTful, but I'm unsure how to deal with the SECTIONS and ASSETS. There are 6 types of sections that a project can have ONE of: Eg. Photos, External Links, About, Videos, etc. There is also a 7th section that a project can have many of (a free-for-all, essentially).

Each of the sections contains one or more asset. For example an About section can only contain one body of text, but a Photos section could contain many photos.

Ideas for approach

If I was writing this using vanilla PHP, I'd probably have an Asset object and then have Photo, About, External Link, that Extended Asset.

The more I've thought about it, the more I've questioned if I even need a Section object, too.

Given that I'm using MVC, I'm not sure whether I should have a different Controller and Model for each Asset type, or if that's overkill. Maybe I should just have an Asset Model (and one Asset Controller), and then have more Models for each of the Asset types that Extends that Model.

I also contemplated having one big Assets table to store them all. Yes, that would have a ton of empty cells, but it wouldn't be a problem in a practical sense, given the small size of the project. (Premature optimization and all that.)

Maybe I'm overthinking it. Maybe I've not thought about it enough. Maybe I'm just not seeing that it's really obvious that I should create lots of different Controllers.

Any assistance to help shape my thinking toward a good use of MVC would be greatly appreciated.

Update: Further thoughts

Having had more time to ruminate, learning more about MVC and think about comments made by @RobertHarvey, I've started thinking more about the Models I've chosen. I come to think that's really where this question (and its solution) lies.

I've started building the site with a model for each SECTION type and ASSET type (eg. VideoSection and VideoAsset are two models I have now.

A Project can have one VideoSection. A VideoSection can have many VideoAssets. Fingers crossed this is a good way to approach this.