In the project I am working on at the minute I have created a
base_service.cfc that provides an init() constructor function which works in
exactly this way.
This works well for the application I am working on right now, but I would
hesitate to put too many rules about how to implement things because it
reduces the flexibility of the system to accommodate project specific
requirements.
Are you extending base_service in your other CFCs? That seems to be a bit dangerous since it introduces a very tight coupling, it doesn't represent an "is-a" relationship and it prevents services from being genuine extensions of other CFCs.
The following are all good solid guidelines for MVC / MVP style programming in general and not specific to BatFink - they apply almost universally to Mach II as well (except where noted):
All data validation is done in the model layer.
All persistent data accesss such as databases, file systems, external systems is done in the model layer.
Neither the Model nor the Presenter layer ever directly generate output for
the user. The only layer that ever creates output is the view layer.
The logic for what to display for any given URL is contained entirely in the
Presentation layer. The presentation layer CFCs will call methods in the
Model and call custom tags in the View to generate the output (normally
HTML).
The Model never calls the View layer directly, and the View layer never calls the Model layer directly.
The only type of logic in the View layer is a boolean test to see whether or
not to display something like a widget based on attributes passed into the
custom tag.
The View layer never interacts with any scope. (For my current project I am
breaking this rule because I have to pass too many attributes that are
effectively constants for the lifetime of a request. I have created a
contextparams structure in the Request scope that contains many of the
attributes I would have to pass otherwise. I am currently considering
whether or not I should keep this as a standard for all future Batfink
projects.)
Note: Mach II encourages Views to use the event object (in request scope) for all data communication but some additional use of bare request scope variables is acceptable. This is a tricky guideline because the 'ideal' is, as Spike suggests, to 'never interact[s] with any scope' but the reality is that parameters have to get into the views *somehow*. Spike's solution - using contextparams - is very simular to Mach II's event object approach.
All exceptions in the Model are rethrown and dealt with in the Presentation
layer. The model may perform some additional processing such as checking for
data integrity, or writing a log, before rethrowing, but the Presentation
layer contains the logic to know how to deal with exceptions.
Note: Mach II differs here a little because it's Controller layer exception handling is very lightweight. Throwing exceptions in Mach II results in an exception event occurring which is then handled by the normal Controller process, although you can re-map events and ultimately you write the exception event handler(s). However, Spike's point is - I think - that exceptions represent internal application control flow and that should be handled by the Presenter (Spike, am I right there?).
Sean A Corfield -- http://www.corfield.org/blog/
"I have always wished that my computer would be as easy to use as my telephone. My wish has come true - I no longer know how to use my telephone."
-- Bjarne Stroustrup
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
