I have
users
id
username
companies
id
areas
id
area_company
id
area_id
company_id
area_company_user
id
area_company_id
user_id
company_user
id
company_id
user_id
area_user
id
area_id
user_id
where
user
has 0 to many areas
AND one area
can have 0 to many users
area
can have 0 to many companies
AND one company
can have 0 to many areas
company
can have 0 to many users
AND one user
can have 0 to many companies
area_company
can have 1 to many users
AND one user
can have 0 to many area_company
area_company_user
has attributes specific to that kind of user
Also, I'm structuring the routes in the following manner
/users
- all existing users/areas
- all existing areas/companies
- all existing companies/areas/{area}/companies
- all existing companies in a specific area/users/{user}/companies
- all existing companies from a specific user/companies/{company}/areas
- all existing areas the company is in/areas/{area}/companies/{company}/users
- all existing users from a company that exists in a specific areaFor 1., 2. and 3. I'm creating controllers that follow the next pattern
AreaController
with methods index(), create(), store(), show(), edit(), update() and destroy()GET /areas, index() method,
GET /areas/create, create() method,
POST /areas, store() method,
GET /areas/{area}, show() method,
GET /areas/{area}/edit, edit() method,
PUT/PATCH /areas/{area}, update() method,
DELETE /areas/{area}, destroy() method.
There's now basically two cases left from that route list
My question is, should I create new controllers for each case since I'd like to perform various actions in each? If yes, that'd mean, respectively
AreaCompanyController
, UserCompanyController
and CompanyAreaController
AreaCompanyUserController
Note: this was a helpful answer but didn't exactly address my concern.
You can see there is already something called nested resource in docs which can cover your cases 4,5,6. In docs there is PhotoCommentController
which you've described that you're using it (question case 1).
For question case 2 you can for example make model for pivot table and have it that way for route and controller. For example AreaCompanyUserController
if I understand well, you have here area_company
pivot table with association of user. So many users can be part of same area_company
association.
You can circumvent Area and Company models use with use of AreaCompany model that would be the pivot model. Knowing id of that pivot model you can easily get associating area, company and users.
class AreaCompany extends Pivot
{
/** code here */
}
Having this, you can name your resource route /area-companies
and /area-companies/{$areaCompany}/users
to avoid triple nesting.
I presume any of these decisions have own consequences like subdirectory planning for controllers, form request files, providers, sometimes even route files.
Probably heard and read for thousand times, but important is to stick with consistent way of it. Consider what could be lesser technical debt in some potential upgrade.