0

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.

Community
  • 1
  • 1
user1440560
  • 163
  • 1
  • 7

2 Answers2

1

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();
Mike Brant
  • 70,514
  • 10
  • 99
  • 103
  • Okay so i get the idea of not having to define a controller for every type of product, and instead use a general "Catalog" controller. But what if some very specific business logic is needed for a type of product? For instance, when a product of the type Cars is sold, an email should be sent to the sales manager, because of the higher price range of the products. This is only the case for products of the type Cars, so you can't include it in your 'normal' Catalog controller. – user1440560 Sep 06 '12 at 22:39
  • @user1440560 I am assuming the controller you were talking about was strictly for item display, not for purchase. It still remains that you could provide an implementation in all of your product class to do post-purchase hooks. Like in `product` class have an method like `post_purchase_hooks()` that can be overridden by all inheriting classes. So can obviously customize the post-purchase logic in each class in this manner. – Mike Brant Sep 07 '12 at 14:10
0

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.

Ivo
  • 5,378
  • 2
  • 18
  • 18