On Tue, 2001-10-23 at 10:09, Gunther Birznieks wrote:
> At 08:46 PM 10/23/2001, Rob Nagler wrote:
> >I don't quite understand the difference between worflow in the front-end and
> >workflow in the back-end. They both change. The danger of making one part
> >of the system easier to change is that people tend to "cheat". They won't
> >put the business logic in the back-end if it takes twice as long.
>
> Yes, people can cheat. But generally the workflow that is most likely to
> change is the UI based workflow. UI isn't just about templates, it's a lot
> about how you go from one screen to the next, or not.
>
> Actually business logic is a bit of a misnomer because there is plenty of
> business logic in the front-end from your choice of fields to the
> javascript to the UI workflow.
I agree. Basically there's front end business logic which defined the
work flow of the client's end (web server/web browser etc). And then
business logic in the middle tier. I've been using Apache/Jakarta Struts
for the front end business stuff, a row of "session beans" (java speak
for purely process related, not data related objects) behind the client
to model work flow and then another row of "entity beans" (java speak
for data object persistence) to get at a rdbms.
This arrangement has worked well for me. This approach makes "cheating"
code look immediately out-of-place, and just downright embarrassing :)
Is there a Perl equivalent to Struts? Mason seems to come close if you
keep yourself disciplined somewhat.
--
pgp: http://www.geocities.com/matthewbk/pubkeyw.txt
PGP signature
