http://www.perlmonks.org?node_id=872527


in reply to How to organize Catalyst stash

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.

my @a=qw(random brilliant braindead); print $a[rand(@a)];

Replies are listed 'Best First'.
Re^2: How to organize Catalyst stash (starting SEVCA)
by ruoso (Curate) on Nov 20, 2010 at 13:06 UTC

    Note that while I agree that the layered scheme is interesting for a lot of scenarios - this is often called "mediator pattern" - it's a common misunderstanding that MVC implies it.

    In MVC the View must have access to the model objects, and must call the model API directly.

    The cause of that misunderstanding is related to the fact that when using the "mediator pattern", the business logic is implemented in the controller, and the model acts just as a "data access object". But in MVC, the business logic resides in the model, which might, in turn, use "data access objects", such as DBIx::Class, to perform its actions.

    The following diagram explains how working with the "mediator pattern" works.

    
      V          C        M
      I   ---\   T  ---\  O
      E   ---/   R  ---/  D
      W          L        L
    
    

    In this scenario, the controller "encapsulates" the model, implementing the business logic.

    If we were to translate that to MVC, the View in "mediator" is implemented by both the View and the Controller in "mvc", the Controller in "mediator" is the Model in "mvc" and the model in "mediator" is just the "data access object" in "mvc".

    That means: when you work with MVC you probably have a set of Model classes that are not the DBIC objects, implementing the access to them.

    daniel
      Thank you for letting me know about MVC. And for note, my code does not use the Mediator pattern (you've allowed your boundary definitions to infer my usage patterns based on my, probably poor, brief summary of coding practice).

      Back to the OPs original question: how do you pass data to your templates? While our off-shoot discussion of MVC is interesting, it isn't answering the question. Your first response to the OP implied that the template IS the view (he asked how to prepare data to pass to the template, you replied he shouldn't do that as the view's job is to serialize the data, thus implying the template IS the view). My answer to the question was, don't pass objects. Hopefully that is clear. Where the data passed gets prepared is another question.

      You'll remember I said that the lines of where the view begins is actually a subject of debate. Some pedantically apply it only to the template (such as your earlier post suggests). Some argue that the view begins with a view encapsulating module (such as your later posts have suggested). Others give the view little more recognition that a few subs.

      My quip about SEVCA was aimed at people who pass objects to their templates, treating their templates as the entire view. You are welcome to do so, the template engines available are certainly powerful enough for you to do so, and I can't argue against your usage of it, but I will never recommend passing objects to your templates. I avoid doing so. What I pass to the template is a contract. If I don't establish the contract, the template will take me for all I'm worth.

      I apologize to the OP for getting caught up in the MVC discussion. One of my strongest issues with Catalyst is that it is set upon strict MVC - but everybody has different feelings for MVC boundaries and implementations. As example: pedantic MVC would require at least three classes/modules to request an email address and send an email, while observation would show you can do valid MVC with three subroutines, if one looks at patterns. Life is too short to worry about whether a solution is academically correct in the Computer Science sense, or where a solution gets the job done and is maintainable in the Programming is craft sense. Sometimes we are lucky and it is both.

      As an aside, to help discredit myself even more, I do not use DBIC or other ORMs. I do not know if it is related, but I have never had to create a View Serialization class (the thought of being in a situation that would require it tires me).

      On the last note, I have enjoyed your posts. You seem to have a very good working knowledge. ++

      my @a=qw(random brilliant braindead); print $a[rand(@a)];