[Catalyst] Controllers, Models and flow control
jtocci at tocci.org
Fri Jun 10 01:56:08 CEST 2005
'Business Logic' is a more ambiguous phrase than I thought. After
some thought, I think I would have been better off using the term
'business rules', but not by much.
David Storrs had this to say to Dominique:
> Business logic is just the set of rules that
> describe what operations should be carried out on the data, and how
> the state should change. "When selling to a customer in Europe, add
> VAT tax to the price" is a business rule. These things have nothing
> to do with widgets...there may be widgets onscreen which are involved
> in gathering information for, or expressing the results of, or
> triggering, business rules, but those widgets are not part of the
> business rule per se.
I agree with David that the business rules are not the widgets and
vice versa, but I think they are related. To me, they are a
substitute for methods. Sometimes the method is overridden and a
value is assigned directly, but its still a method. Sometimes the
method will change a data format, sometimes it could modify your
view, like prettying up column names. As David pointed out, it might
figure your tax. I think rules are best used to configure your
components. Methods that work on your data I would put in the model
and I'm not referring to them at all.
Figuring your tax might work as a method in your model, but the
information for which tax to apply is likely to be in your session,
whereas a method in the model would be more appropriate when the
input has to be found on disk. I reason, figure the tax when the
session is in hand, then send out to view or commit to disk.
Additionally, to put a method in your model to change a data format
for some customers and not others could be wasteful. It doesn't
concern the database, and might incur a performance hit due to a
change in data type, higher in the model would be better, but it
would also need logic to determine when to show one format, and when
to show the other. This is again information that should be in the
session, hence it would make more sense to decide when your session
A widget may be reusable in the sense that more than one customer can
use it, but this should be taken for granted. Reusability should be
more about using the same widget in more situations. Rules allow you
to configure widgets so that they can fit more situations. In David's
example above, three rules about figuring tax would allow you to
reuse your tax page for three tax situations, and you wouldn't have
to change the code for the page to add a fourth. That's my definition
of a reusable widget.
I would argue that without rules, you can't have reusable widget at
all. If you have an object, say a page view, hard coded to display a
list of items, it has to be re-written to display a different list.
That isn't a reusable widget. Now if you can tell it what category of
items to display when you call it, then its reusable, and the
configuration information you sent constitutes a rule to me.
Now, I advocate putting all such rules in one place. Separately, I
advocate giving rules a 'scope' so that you can assign properties to
more that one widget at a time. I also like the idea of having a
priority level so that you can have a base of default rules and build
on them for more and more specific situations. But, a rule, to me, is
something every OO program uses every time it configures an object.
I'm not talking about instantiation, but configuration, and they
don't belong in the model for practical reasons.
Fort Worth, Texas
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Catalyst