You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by hicham abassi <ha...@gmail.com> on 2006/07/17 17:04:55 UTC

Re: what is the best practice?

Check the book "POJOS in action" , there are some good chapters about Ibatis

On 5/25/06, Rafael <ra...@gmail.com> wrote:
> Hi,
>
> I've been enjoying these conversations about 'Architecture'/'Best Practices'
> etc..   Does anyone knows if there is a specific list somewhere to get more
> information about architecture decisions, etc ???
>
> -Rafael T Icibaci
>
>
> ----- Original Message -----
> From: "Adam Hardy" <ah...@cyberspaceroad.com>
> To: "Struts Users Mailing List" <us...@struts.apache.org>
> Sent: Monday, May 22, 2006 6:49 PM
> Subject: Re: what is the best practice?
>
>
> > Hi Joel,
> >
> > the methods you mention are all data access calls, not business methods,
> > because business methods would actually carry out some form of business
> > logic on the data.
> > But anyway your methods are OK. It just corresponds to the number of ways
> > your app needs to access the data. There would be no reason to reduce the
> > number of methods, although you should make sure that you are not repeated
> > large amounts of code. With iBatis I think you would avoid that.
> >
> > Regards
> > Adam
> >
> > Joel Alejandro Espinosa Carra on 22/05/06 17:39, wrote:
> >> Thank you Adam, Paul:
> >>
> >> I will try iBATIS as you suggested to me. I have another question to you
> >> in the same context. In this MessagesManager class I have business
> >> methods like getAllMessages() that retrieves all the messages from the
> >> database, but I also have another business methods like
> >> getMessagesForUser(String user_id), getMessagesForMonth(int id_month),
> >> etc. in my opinion this will make this class have eventually a lot of
> >> business methods, what is the best way to handle that?
> >>
> >> Again, thanks for your help.
> >> Best regards.
> >>
> >> ps. Paul Benedict like Ocean's eleven?
> >>
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org