Controller, Model and URL best practices

Yii 2.0 General Discussions
1

Hi,

Up until now I’ve just used Yii as a back-end framework for building a CMS. In doing that, there’s been a very tight and clear relationship between the url in the application, the Controller and the Model.

Each model has its own controller and set of views - and the urls of the CMS match these closely.

Now that I’m building a complex front-end site, I’m finding that’s not the case.

For instance - a site might have these menu items

Home

Products

Community

About

with a wide range of pages within each site section. "Products" might contain a testimonials page that pulls from a table of testimonials, and it might contain several text only pages that describe product generalities, return policy, etc… and these might pull data from a table of site pages. Then the product pages themselves will come from a product table, etc…

My question boils down to this: does the menu drive what’s in the controller, or the data?

Is the best practice to have one “Product” controller that deals with any page that’s under the “Product” section - and handles all the separate models - testimonials, site_pages, products?

this would make it simple to keep my urls consistent across "Product" pages: http://mysite/product/some_action

Or… should each controller be pretty much restricted to handling mainly one model - in which case I should be routing people to a separate testimonial controller, site page controller, and product controller. But then I’m stuck having to come up with some complex URL Manager rules to make sure that the urls still look like:

http://mysite/product/some_action

and this could get pretty convoluted.

Any ideas from the Yii community on what the best practice is here?

-Charlie

2

My thoughts:

I would keep one product controller and have actions for each page under products (depending on how big the products section is). Your menu doesn’t have to reflect your controller/action structure in any way, but it might be wise to keep it that way for your own sanity.

I don’t think you need to keep one controller per one model either (unless your application is dead basic).

You should decouple your logic though so you don’t have masses of code in each action, this will keep your controllers lean and easier to manage. It’s worth building components/helpers to help with the backend logic, that way your backend code is a lot more reusable and not “controller dependant” as otherwise it may eventually become “spaghetti code”.

If your products section is huge though, it could be worth looking in to creating a product module so you have that extra level of code separation.

Cheers

Ash

3

Thanks a lot for the advice - sounds like it’ll make my life easier, as long as I put in the extra work to keep the controller lean, as you put it.

Regarding the module - if I get what you’re saying, the advantage here is that I’d be able to create many controllers to handle product actions, while still cleanly retaining the url structure I want. But then I’d need to balance that advantage against the extra complexity of having another “sub application” inside my application.

All stuff to think through as I map this out.

Anyone else - feel free to dive in to the conversation…

Thanks,

-Charlie

4

Yep, it’s all about the scope of the project.