OM - Peer design questions

[Channing Walton <ch...@mac.com>]

Hi,
I would like to know what is generally considered best practice regarding
the layers of a system built on torque/turbine.

I may be wrong but the way I see it is this:

1. All GUI stuff (velocity in my case) should go through actions, pull tools
and business objects (ie not Base and Peer classes)
2. The actions and pull tools should talk to the business objects only
3. The business objects can talk to peer objects if necessary

This approach seems like a sensible/standard layered approach, and what the
intent seems to be in turbine.

Is this correct?

Channing

-- 
Channing Walton
http://homepage.mac.com/channingwalton


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: OM - Peer design questions

[Channing Walton <ch...@teaminabox.co.uk>]

On 16/8/02 1:49 pm, "Steve K." wrote:

> That approach sounds logical to me.  I would like to add to your questions,
> if I may.

Of course :-)

> 4.  If the peer access is done only through business objects, and thus
> separated from the view layer, what is the best way to past data to the
> business objects?   Should RunData be passed into the business objects? Or
> should the ParameterParser from RunData be passed in instead so that the
> SetProperties method can be used.  It seems like unnecessary work if you had
> to parse RunData into some DTO type mechanism or just into parameters, and
> pass that to the business objects.

What I've been doing is to get anything out of rundata that I need in my
actions, and then prod the model with those objects. So my model doesn't
have rundata stuff in it.

(Also, it helps unit testing the OM if the rundata isn't around.)

Channing 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: OM - Peer design questions

["Steve K." <sk...@comcast.net>]

That approach sounds logical to me.  I would like to add to your questions,
if I may.

4.  If the peer access is done only through business objects, and thus
separated from the view layer, what is the best way to past data to the
business objects?   Should RunData be passed into the business objects? Or
should the ParameterParser from RunData be passed in instead so that the
SetProperties method can be used.  It seems like unnecessary work if you had
to parse RunData into some DTO type mechanism or just into parameters, and
pass that to the business objects.

I have just started using Turbine, so I may be pondering things that are
common knowledge by now.  Sorry, I am just a caveman.

- Steve


----- Original Message -----
From: "Channing Walton" <ch...@mac.com>
To: "Turbine" <tu...@jakarta.apache.org>
Sent: Friday, August 16, 2002 8:17 AM
Subject: OM - Peer design questions


> Hi,
> I would like to know what is generally considered best practice regarding
> the layers of a system built on torque/turbine.
>
> I may be wrong but the way I see it is this:
>
> 1. All GUI stuff (velocity in my case) should go through actions, pull
tools
> and business objects (ie not Base and Peer classes)
> 2. The actions and pull tools should talk to the business objects only
> 3. The business objects can talk to peer objects if necessary
>
> This approach seems like a sensible/standard layered approach, and what
the
> intent seems to be in turbine.
>
> Is this correct?
>
> Channing
>
> --
> Channing Walton
> http://homepage.mac.com/channingwalton
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>