Fran (et al)
I've stayed out of the MVC chitchat for a long time (very interesting
thread) because it's such a deep topic. But seeing as how Fran has
some concrete questions...
> 3. How do you prevent a Controller from just becoming another big if
> statement, or is this their purpose in life?
See Jeff's previous mail. Your structure is crying out for a dispatch
table; Jeff suggests building this out of a hash that defines what
actions to perform based on what your query values are. That's a great
place to start. GET RID OF YOUR BIG "IF" STATEMENT ASAP.
> 6. Do you need to create objects at all? Is OO a prerequisite to
> MVC?
No, but it makes it a lot easier in most cases. Passing objects between
the M, the C and the V is way easier than building crappy hashes by
hand and calling a zillion "param" methods.
> 7a. Is it insane to leave my SQL hard-coded in there? The queries
> don't change all that much, and it's nice to have the query in the
> same place as the processing of the result set so you can kind of
> "see" the structure of the result set better. This helps our
> less-experienced developers.
OK, strong words here. REMOVE YOUR SQL. Move it into a layer that
deals with the DB and vends consistently formed data (objects if you
can manage it). Your controller shouldn't know anything about your
DB, so create a class that essentially is every entry and exit point to
and from your DB, and have that keep the database handle as a class
variable. What's easier for your newbie programmers... your code as it
is now, or this:
sub doDoctorActivity {
my $tmpl = shift;
my @results = DataStore::objectsForDoctorActivity();
ViewManager::someMungingMethod($tmpl, \@results);
return $tmpl;
}
Think of how clean your code is with no more $dbh references or "ifs".
Think how many fewer lines of code you will have to maintain. Fewer
lines is good. Remember that.
It is a HUGE gain to isolate your DB entry points and place them in one
carefully controlled class.
I am often amazed at how blind some developers can be about SQL. Most
of the people on this list realise that mixing HTML and perl is bad,
and most of us can see why. But I am constantly depressed that not
nearly as many people appreciate that it is THE SAME FOR PERL AND SQL.
SQL intermixed with Perl is just nasty and you need to move it into a
limited space that you can easily control. Obviously, it's necessary;
you need your perl to talk to your DB. But it should be very very
carefully managed and moved somewhere where its impact on the source is
minimal. Right now I have the evil task of optimising a zillion lines
of bad perl code written by a company I used to work for. They have
asked me to come back and save the project... and it's a frigging mess
because of all the SQL. THere are so few places where you can cache
query results, for example, because there are pages and pages of crap
like
$sql .= " AND some_other_stupid_table.id =
another_dumbass_table.stupid_table_id";
if ($myAssIsBlue) {
$sql .= " AND some_table.my_ass IN ('BLUE','BLUISH','CYAN')";
}
ad nauseum. What a load of utter shite.
> 7d. Or do I -really- want an object/structure that represents every
> result set we need to get back from the database?
If I were you I would create a parent class that represents a basic DB
row and use that. When you need custom behaviour, subclass it and
bless the rows into the subclass. Adding an "Object Structure" can be
as simple as blessing your hashes that come back from the DB into a
class, remember that.
> 8a. What structures are used to pass back the data from the model
> through the controller to the view?
> 8b. The view is expecting HTML::Template style hashes and arrays, do
> I form these in the model (which seems to be too much knowledge of
> the view while still in the model) or does the controller convert it
> to the structures expected by the HTML::Template view?
> 8c. The model is getting DBI record sets from the db. I have to put
> this data into -something-, why not the exact format that
> HTML::Template view needs rather than process it twice?
Well, pretend you actually had objects coming back from your DB. Surely
your controller should pass those objects to your view as is...?
That's the whole point. Your view should be responsible for
displaying them. I have seen a lot of talk about HTML::Template being
a "View" layer. It's not. It's the bottom of the View layer. You
need to write the top of the view layer yourself, that takes your data
(objects, whatever) and vends it to HTML::Template in the right way.
Kyle Dawkins
Central Park Software
