I'm starting a campaign for SEVCA also known as Stop Egregious View Controller Abuse.

What is SEVCA? SEVCA occurs when the View has Godlike access to the Model and takes it upon itself to act like the Controller. It occurs when developers pass raw unprotected models to the View, and template designers then take over and introduce Controlling business logic into the template. This is typically only possible when using higher power template systems such as Template::Toolkit, Template::Alloy, or HTML::Template::Expr. This problem does not normally result with lower power template systems like HTML::Template or Text::Tmpl.

What can I do to prevent SEVCA? Stop passing your raw unprotected models to your View. While doing so may allow you to get quick and dirty work done, long term maintenance is hampered by having to figure out if the Controller really is in control or if the View is, or sometimes both are.

In all seriousness, trying to enforce the boundaries of MVC often ends up as a pedantic debate. In the end, use what works best for you. After 12 years of programming CGIs (short compared to some here I know - and yes this advice applies to Catalyst, CGI::Application, CGI::Ex::App or any other flavor of the month) I have found that what works best for me (notice I said "for me") is to only pass a hashref of needed values to the template - and nearly never ever pass a raw object. Sometimes at the extreme end my hashrefs may contain hundreds of thousands (literally) of values organized into arrayrefs of hashrefs of lists, but more often than not it is a hashref of 0 to 100 values arranged into useful data structures.

Why keep it simple? Because template designers will use everything you pass, and because it is nice to be able to look at the code and see exactly what template needs so when (not if) you refactor your CGI you know exactly what the template needs without having to read the entire template. (Update: this does open up part of the discussion about where does the view begin. Some say that the lines are drawn at object boundaries, some say that the Template Engine/template are the view, some would argue the boundary begins in a "prepare_template" type of routine, and I'd say that all of the above are correct depending upon the skill/knowledge/needs of the developer, and then I'd say get the job done already because the clock is ticking)

The best legacy a developer leaves is readable maintainable code.