I\'ve been struggling for some time now with exactly how to recode a page-based PHP application using an MVC framework. Just for background, I am having to move the app into MVC
What is the point of having one view per controller? What need is there for a separation of concerns when everything is just pair matched?
I'd be more inclined to write a controller that controls several views that are related in some way. For instance, the aforementioned add/view/edit of a user. You'd want to keep similar functionality together rather than searching through many files for the code you want. It's also handy to have all the methods defined (for a particular object) in one place. Makes maintenance MUCH easier.
I worked on a project using a PHP framework that created a separate file per 'action'. Named like 'object(action)' and it became a NIGHTMARE to maintain.
I've been using Django for a little while now which keeps all the models in one file, all the views (controllers) in one file, and the templates (views) separately. [Django isn't MVC but for these purposes let's pretend it is]. This allows you to group together common code in one place and maintenance becomes much easier.
My only advice is - don't try to organise your project based on some ideal of MVC. Organise your project how it makes sense to you and your domain. MVC was proposed to limit complexity, not increase it.
For your plan example, I would make that into a controller. www.example.com/plan/1 .. /plan/2 etc. It makes sense because the actions are logically grouped together to form some task.
A controller, in my opinion, should be used for managing a task or an object. It's methods should be the specific actions required to complete that task or modify/use an object.