CODEWITHSUNDEEP
phpmodel-view-controllerfront-controller
user1440560
user1440560

Reputation: 163

Nesting controllers with the Front Controller Pattern and MVC

I'm developing a web application in PHP using an MVC-approach (not using any framework, pure PHP). As is often the case with MVC, every request arrives at a front controller which routes it to the corresponding controller, and executes the requested action. The URL structure looks like this:

www.site.com/controller/action

Let's say I'm building an e-commerce site which has products in different categories. Possible URLs could be:

www.site.com/sofas/overview
www.site.com/video-games/overview

For the first URL, the "sofas" controller is loaded, and the overview() method of it is executed. This all works well until we have to nest these products within parent catagories. I'll take the two previous URLs to demonstrate what I mean:

www.site.com/furniture/sofas/overview
www.site.com/electronics/video-games/overview

Now, the "video-games" controller is nested within the "electronics" controller. However, with the current 'load controller -> execute action' structure this won't work.

A possible solution would be to create a method within the parent controller ("electronics") which gets executed in case an unexisting action is requested ("video-games"). This method checks whether the requested action exists as a controller. If so, the controller gets loaded and the action ("overview") of it gets executed.

I fruitlessly searched for solutions to this limitation of the standard front controller pattern, including here on SO. I think my implementation of MVC is now correct, but the front controller still brings limitations.

Upvotes: 0

Views: 642

Answers (2)

Mike Brant
Mike Brant

Reputation: 71384

I think the thought that you have to have a different "controller" for each different product type may where you are running into problems.

Unless you are going to have drastically different views for each product type, I would think the controller would be linked to a concept such as "catalog" (or "product" or whatever you want to call it). So for example your URL structure might look like

www.site.com/catalog/furniture/sofas/overview
www.site.com/catalog/electronics/video-games/overview

With the catalog portion of the URI determining the controller and the additional URI segments in essence being parameters passed to the controller indicating the specifics of the request.

This would work nicely with an OOP inheritance structure in that you could have a root 'product' class, and then extend that class with subclasses for furniture, electronics, etc. which would each have their own properties specific to the category. You would the further sub-class for sofas, video games, etc.

All your controller would have to do is evaluate the request URI to determine which class to load for the request. So something like:

// assume URI has been parsed to get value such as "sofas", "video-games", etc. into a variable called $class_to_load
$product = new $class_to_load;
$product->overview();

Upvotes: 1

Ivo
Ivo

Reputation: 5420

You are confusing MVC structure with routing issues.

The controller should be probably something like a product controller, or a category controller. Group controllers by functionality.

Now routing deals with the structure of the request and where this gets sent in the application.

You should have a routing layer that knows (for example) to send /<category>/<subcategory>/<action> to the appropriate controller (say products controller) with appropriate arguments (i.e category and subcategory) so it can construct a response.

Only directly mapping the url to controller and action (i.e enforcing /<controller>/<action>) is a very limited way of constructing the architecture of your application.

Upvotes: 0

Related Questions