MVC (Re: DBIx::Class - Related Tables)

[Andy Wardley]

Raphael Mankin wrote:
> The problem here is not with the ORM but rather that you are breaking
> the MVC separation and putting controller logic in the view. A good ORM
> would have its data cached so that your test might not require two SQL
> queries. However, the template is, in this instance, the wrong place to
> put the test.

I disagree.  In fact, I think you may have fallen into the MVC Silver
Bullet[*] trap.

There are many different kinds of logic in a web, including application
(business) logic, web framework logic (e.g. routing requests and responses to
and from handlers), access logic (authorisation and authentication), data
logic (both internal ORM mapping and external entity modeling) and
presentation (view) logic.

Each has its own place, and the place for presentation logic is in templates.

    [% # display custom panel based on user status
       IF user.is_admin;
          INCLUDE admin/controls;
       ELSIF user.is_logged_in;
          INCLUDE user/greeting;
       ELSE;
          INCLUDE user/login;
       END;
    %]

It is not up to the framework, the application, the controller or the ORM
to decide how this information should be presented to the user.  This is
the domain of the web designer / information architect / usability consultant
and the templates are their playground.

It is the responsibility of the ORM to make a user look like a black box
object that has an is_admin method that will tell anyone who asks of it if
this user is an administrator.  It is the responsibility of the web
framework controller to map the request for this page to the appropriate
handler, and to perform any additional authentication/authorisation/setup
It is the responsibility of the application handler to ask the ORM to
fetch a user object for the current user, and perform any other operations
relevant to the task at hand.  Then it hands those objects over to the
template (or some other front-end presentation mechanism) along with any
other information it needs to render the outcome to the user in whatever
manner it deems appropriate.

These are all separate responsibilities and should be treated as such.

If you lump all the different kinds of application logic into one monolithic
"all logic is controller logic" category then you end up with bloated
controllers and a much weaker separation of concerns.

A

* http://wardley.org/computers/web/mvc.html