Thank you everyone for your input. I will research a little further
to see how I am going to do this.
On Tue, Feb 26, 2008 at 5:17 PM, Randy Burgess <[EMAIL PROTECTED]> wrote:
> > From: Richard Sayre <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List <user@struts.apache.org>
> > Date: Tue, 26 Feb 2008 15:32:56 -0330
>
> > To: Struts Users Mailing List <user@struts.apache.org>
> > Subject: Re: Struts 2 and SOA
> >
>
> > Ok. All of my actions call my DAOs for their logic. Most of my
> > actions look like this:
> >
> >
> > public String myActionMethod() {
> >
> > myDAO.getARecord();
> >
> > //populate the action with record fields (will be displayed on a
> > form or table etc)
> >
> > if (someField = Status.EDIT && user.hasFullAccess() ) {
> >
> > fullAccess = true;
> >
> > } else {
> > readOnly = true;
> > }
> >
> > }
> >
> > The most 'busniess logic' that my action contains is setting
> > variables based on database information (fullAccess or readOnly). Im
> > not sure if this should be moved out of here and into the DAO or not.
> > also might have a save() method that determines if I should call add
> > or update on my DAO.
> >
>
> Are fullAccess or readOnly used in your view? How would you expose them if
> you put them in a service layer? If they are used in the view then it seems
> to me like they have nothing to do with the service and shouldn't be there.
> Maybe an interceptor would be a better idea if this logic is sprinkled
> throughout your S2 application.
>
>
> > So, would I expose my DAO as a service? Is this a good Idea? DO I
> > need to add another layer (POJO) or would that be overkill? If I do
> > have some security logic in my Action, should this be moved to a POJO
> > that calls the dao and set up its own members, isReadOnly, hasAccess
> > etc. I also do some data validation in my action, ie I check to see
> > if the data passed to my action is allowed to be accessed by that user
> > (this aviods URL rewrting and re writing POST data with proxy
> > servers). So I get an id of something the uesr wants to access and I
> > make sure that user is allowed to access it. Should this be moved out
> > of the action? Did I make a mistake putting it there? If so I
> > imagine putting this logic in to a POJO which controlla access to the
> > DAO, then the action calls the POJO or web service. I guess then the
> > POJO and DAO become my Model and no busniess logic is in the action at
> > all. Now that I think about it, this seems like a good idea. I was
> > new to MVC when I was thrown into Struts 2 so hopefully this misake
> > does nto ccost me too much time. If I do this, (Action -> POJO ->
> > DAO) then I would expose the POJO as the web service?
> >
> > Thank you for your input,
> >
> > Rich
> >
>
> I recommend checking Amazon for books on SOA or checking out some of the
> excellent web sites devoted to it. I googled and came up with this, which
> looks pretty good for a start. This is a huge topic in and of itself but it
> doesn't really have anything to do with Struts.
>
> http://java.sun.com/developer/technicalArticles/WebServices/soa3/
>
> Randy
>
>
>
> >
> > On Tue, Feb 26, 2008 at 3:05 PM, Randy Burgess <[EMAIL PROTECTED]> wrote:
> >>> From: Richard Sayre <[EMAIL PROTECTED]>
> >>> Reply-To: Struts Users Mailing List <user@struts.apache.org>
> >>> Date: Tue, 26 Feb 2008 14:08:18 -0330
> >>
> >>> To: Struts Users Mailing List <user@struts.apache.org>
> >>> Subject: Re: Struts 2 and SOA
> >>>
> >>
> >>> Could you elaborate a bit. Would the POJO contain the Business logic
> >>> for calling My DAO and other classes? Would the POJO replace the
> >>> action functionality? Then my action would use a POJO to do all of
> >>> the work? So any logic in MyAction.save() would go into POJO.save()
> >>> which would then be called form my action? That way My POJO could be
> >>> accessed from my struts application and any other clients that need it
> >>> functionality? I dont see any need for .NET interoperability in the
> >>> future, but it would hurt to have that option. The main reason for
> >>> this is we are designing a new J2EE Application seprate from our
> >>> current system. In the future we want to beable to access certian
> >>> functionality of each of these systems. So System A will be asking
> >>> System B for info and doing some work based on that info.
> >>
> >> What you are describing here is essentially the standard MVC pattern. The
> >> business object doesn't have to be a POJO. In general there should be no
> >> business logic in your action, it should be in some external class such
> as a
> >> POJO, EJB or web service of some sort.
> >>
> >> Randy
> >>
> >>
> >>
> >>
> >>
> >> This email and any attachments ("Message") may contain legally privileged
> >> and/or confidential information. If you are not the addressee, or if this
> >> Message has been addressed to you in error, you are not authorized to
> read,
> >> copy, or distribute it, and we ask that you please delete it (including
> all
> >> copies) and notify the sender by return email. Delivery of this Message
> to
> >> any person other than the intended recipient(s) shall not be deemed a
> waiver
> >> of confidentiality and/or a privilege.
> >>
> >
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
>
>
> This email and any attachments ("Message") may contain legally privileged
> and/or confidential information. If you are not the addressee, or if this
> Message has been addressed to you in error, you are not authorized to read,
> copy, or distribute it, and we ask that you please delete it (including all
> copies) and notify the sender by return email. Delivery of this Message to
> any person other than the intended recipient(s) shall not be deemed a waiver
> of confidentiality and/or a privilege.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
