[Catalyst] Program the logic

Brandon Black blblack at gmail.com
Thu Jun 29 13:49:51 CEST 2006


I really don't see much ambiguity myself.  I'm not really a theorist
on this stuff, so what follows is my practical definitions based on
working with it:

Model(s) - Data source abstraction.  You put things like access to
RDBMSes, Files (collections of images?), and even remote data sources
served via XMLRPC or screen scraping here.  The point of this layer is
to encapsulate and abstract the access methods for the data sources,
and do simple transformations that are directly related (for instance,
translating between DB timestamps and DateTime objects, or calculating
a user's age based on the stored birthdate in his database entry).

The best way to determine if a peice of code belongs in a Model is to
ask yourself: "If someone were to write a completely different
application for a completely different purpose using a completely
different architecture (perhaps not even web-based at all) which also
needed access to this data source, would this peice of Model code
probably be appropriate and/or useful for them?"

Views(s) - View-windows on your application.  In theory, you might
have several views: an HTML view, a graphing view (for outputting
GD::Graph images), a PDF view, etc.  The only knowledge that belongs
here are the details involved in constructing the specific flavour of
output.

If you find yourself putting code in your View templates that isn't
directly related to rendering this specific flavour of output, it
probably needs to be moved to the Controller.  Good code in views:
iterating an arrayref to generate a <ul> list, walking a data
structure to generate a <table>, or walking a data structure to
generate a graph image.

Controller(s) - This is the glue that binds Models and Views together.
 It accepts user input, possibly makes modifications to Model data,
possibly retreives some Model data, and then displays a View at the
user who gave the input.  This is where the business logic goes.  This
is where anything that officially doesn't belong in Views and Models
goes, basically.

If you find yourself putting any HTML tags in your controllers, that
code really belongs in your Views.  Similarly, if you find yourself
putting raw SQL or raw requests to remote network sources, etc in your
controllers, those really belong in proper Models.

That's the ideal situation in my mind.  Obviously in the real world
you sometimes deviate from this, for reasons like "I don't have time
to design the proper abstraction before this looming deadline", or
"doing it the right way is just provably too inefficient in this
particular case".  But its important to keep the ideal in mind and
strive for it.

-- Brandon



More information about the Catalyst mailing list