You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Nic Werner <we...@sonoma.edu> on 2005/05/04 05:03:47 UTC
Seperation between Controller and Model
Hi again,
My apologies for a probably obvious problem. I've got an example
where I need to check (on update) if this object is actually being
'moved' (ie, keypair is being changed), and if there is already data at
the dest. keypair, go back to the page, display both objects and confirm
the user wants to overwrite the actual data there. If confirmed, null
out the old keypair data and update the new keypair.
Now, I'm confused on where I should put the logic for all this? This
almost seems like the perfect place for custom Validation code, and
seems like something the Controller would do, but it also seems that
this is business logic and shouldn't be coupled to Struts. I'm thinking
that all Struts should call is my DTO.Update() method?
Maybe because I don't have much so-called business logic in this
application that I'm not sure of what really should be in that layer,
the above example is about as complex as the logic gets for me.
Thanks,
- Nic.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Seperation between Controller and Model
Posted by Michael Jouravlev <jm...@gmail.com>.
Um, what is a keypair? A primary key?
I personally prefer to have "store" actions and "view" actions. In my
"store" action I would call some business code which verifies that
object can be saved automatically. And if not, then if "overwrite"
flag is set by client. If yes, store and show "view".
If not, show "view" with both objects and with checkbox/button to
overwrite. On submit go to "store" action again. This time "overwrite"
checkbox would be set.
On 5/3/05, Nic Werner <we...@sonoma.edu> wrote:
> Hi again,
> My apologies for a probably obvious problem. I've got an example
> where I need to check (on update) if this object is actually being
> 'moved' (ie, keypair is being changed), and if there is already data at
> the dest. keypair, go back to the page, display both objects and confirm
> the user wants to overwrite the actual data there. If confirmed, null
> out the old keypair data and update the new keypair.
>
> Now, I'm confused on where I should put the logic for all this? This
> almost seems like the perfect place for custom Validation code, and
> seems like something the Controller would do, but it also seems that
> this is business logic and shouldn't be coupled to Struts. I'm thinking
> that all Struts should call is my DTO.Update() method?
>
> Maybe because I don't have much so-called business logic in this
> application that I'm not sure of what really should be in that layer,
> the above example is about as complex as the logic gets for me.
>
> Thanks,
>
> - Nic.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Seperation between Controller and Model
Posted by Leon Rosenberg <st...@anotheria.net>.
your problem seems to be 100% presentation. Business logic shouldn't
know anything about confirmation pages, because it's not a part of the
business use case.
Business logic should provide you the methods to perform the checks.
like:
in First Update Action:
if (service.hasKeyPairMoved())
sendToConfirmationPage(newKeypair, service.getKeyPair());
else
service.updateKeyPair();
in Second Update Action (after confirmation)
service.updateKeyPair();
regards
Leon
P.S. DTO.Update() method? I thought DTO where a POJO?
On Tue, 2005-05-03 at 20:03 -0700, Nic Werner wrote:
> Hi again,
> My apologies for a probably obvious problem. I've got an example
> where I need to check (on update) if this object is actually being
> 'moved' (ie, keypair is being changed), and if there is already data at
> the dest. keypair, go back to the page, display both objects and confirm
> the user wants to overwrite the actual data there. If confirmed, null
> out the old keypair data and update the new keypair.
>
> Now, I'm confused on where I should put the logic for all this? This
> almost seems like the perfect place for custom Validation code, and
> seems like something the Controller would do, but it also seems that
> this is business logic and shouldn't be coupled to Struts. I'm thinking
> that all Struts should call is my DTO.Update() method?
>
> Maybe because I don't have much so-called business logic in this
> application that I'm not sure of what really should be in that layer,
> the above example is about as complex as the logic gets for me.
>
> Thanks,
>
> - Nic.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org