struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <dgraham1...@hotmail.com>
Subject Re: Architecture advice....
Date Mon, 29 Jul 2002 21:11:03 GMT
Now we're onto "how to design a factory method" :-).  So if you have many 
different service objects you could just compose your ServiceFacade of these 
objects and publish their interfaces.  This is the true use of the facade 
pattern so your code doesn't need to know about all of the objects behind 
the facade.  You would do this like so:
ServiceFacade{
private SpecialServiceClass special;

public doService(){
   special.doService(); //delegate call to internal service object
}
}

Notice that all interaction with SpecialServiceClass is done through the 
facade leaving you free to rip out SpecialServiceClass in the future and 
replace it with something else.

If you really want to do the factory thing you have 2 options:
1.  A factory method for each service class
  public SpecialServiceClass createSpecialServiceClass()...
  public SpecialService2 createSpecialService2()...

2.  One factory method with parameter telling which type of service class to 
return.  public Object create("SpecialServiceClass")

I would go for the facade pattern so most of your code only knows about the 
facade and not the implementation classes.

I hope this helps.


>Graham,
>
>thereīs just one more question that I have concerning your method.
>
>Obviously there will be many different objects which make up the service
>facade.  Does that mean that one has a "factory" for each object; i.e. each
>"factory" returns itīs type of instance,  or do you pass a parameter to the
>"factory" and return an instance accordingly?
>
>Thanks for your time.
>
>Michael
>
>
>----- Original Message -----
>From: "David Graham" <dgraham1980@hotmail.com>
>To: <struts-user@jakarta.apache.org>
>Sent: Monday, July 29, 2002 9:59 PM
>Subject: Re: Architecture advice....
>
>
> > I chose not to implement a session facade in my current project but have
> > done it this way in other applications.  I really dislike bunches of
>static
> > method calls so this solution works nicely.  I mispoke when I mentioned
>the
> > factory method; it would only create the singleton instance on the first
> > request, after that it would always return that instance.  You would use
> > your service layer like this:
> >
> > // returns same instance every time
> > ServiceFacade sf = ServiceFacade.getInstance();
> > sf.doSomeServiceMethod();
> >
> > instead of
> >
> > ServiceFacade.doSomeServiceMethod();
> >
> > Sure, it's one more line of code but it is a cleaner design to me.
> >
> > >Yep, thatīs exactly what it sounds like :-).  I would like to implement
> > >something similar to the session facade used in EJB environments.
> > >
> > >I like the singleton idea.  Have you implemented this yourself.  What 
>are
> > >your experiences in doing it this way?
> > >I take it that the factory would do the job of making sure that only 
>the
> > >existing instance is returned and if gone, create a new one.
> > >
> > >Have I got that right?  I certainly like the idea.
> > >
> > >Regards,
> > >
> > >Michael
> > >
> > >
> > >----- Original Message -----
> > >From: "David Graham" <dgraham1980@hotmail.com>
> > >To: <struts-user@jakarta.apache.org>
> > >Sent: Monday, July 29, 2002 8:59 PM
> > >Subject: Re: Architecture advice....
> > >
> > >
> > > > Sounds like a "how to implement a facade" problem.  I would make 
>your
> > > > service layer a singleton with a factory method to retrieve the
> > >instance.
> > > > That way you avoid the static method calls and maintain the 
>symantics
>of
> > > > passing messages to objects (the singleton).  You also avoid 
>creating
>a
> > >new
> > > > object everytime you want to use a service method.
> > > >
> > > >
> > > > >Hi,
> > > > >
> > > > >I had a discussion at work today concerning the best way to 
>implement
> > >our
> > > > >application.  A very
> > > > >basic discription of the framework would be the following:
> > > > >
> > > > >1. Struts + Velocity for the view
> > > > >2. Struts ActionServlets for the controller
> > > > >3. Service layer/methods for querying persistence layer
> > > > >4. OJB persistence layer
> > > > >
> > > > >The main debate was actually about what the service layer would 
>look
> > >like.
> > > > >We thought about the following options:
> > > > >
> > > > >1. The service layer consists of static methods
> > > > >2. The service layer would consists of normal classes
> > > > >3. The service layer could consist of servlets
> > > > >
> > > > >The idea is that (this is nothing new of course) the service layer
> > >would
> > > > >purely have methods such as addToShoppingBasket() or checkLogin();
> > > > >basically
> > > > >service methods which carry out the communication with the
>persistense
> > > > >layer
> > > > >and returns the result to the controller.
> > > > >
> > > > >The question is though, should we create a new object every time we
> > >want
> > >to
> > > > >access a stateless method?  Surely that would be a bit of an
>overhead.
> > >Go
> > > > >with servlets?  This possibly ties it to the web-container too much
>and
> > > > >isnīt very elegant (?).  Another option would be just to use static
> > > > >methods;
> > > > >can this cause a problem when wanting to distribute to more than 
>one
> > > > >server?
> > > > >Is it better in terms of performance?
> > > > >
> > > > >I would really appreciate some help and ideas on this.  It would 
>make
> > > > >things
> > > > >easier in terms of deciding on the next step.
> > > > >
> > > > >Thanks in advance!
> > > > >
> > > > >Regards,
> > > > >
> > > > >Michael
> > > > >
> > > > >
> > > > >--
> > > > >To unsubscribe, e-mail:
> > > > ><mailto:struts-user-unsubscribe@jakarta.apache.org>
> > > > >For additional commands, e-mail:
> > > > ><mailto:struts-user-help@jakarta.apache.org>
> > > >
> > > >
> > > >
> > > >
> > > > _________________________________________________________________
> > > > Chat with friends online, try MSN Messenger: 
>http://messenger.msn.com
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > ><mailto:struts-user-unsubscribe@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > ><mailto:struts-user-help@jakarta.apache.org>
> > > >
> > >
> > >
> > >--
> > >To unsubscribe, e-mail:
> > ><mailto:struts-user-unsubscribe@jakarta.apache.org>
> > >For additional commands, e-mail:
> > ><mailto:struts-user-help@jakarta.apache.org>
> >
> >
> >
> >
> > _________________________________________________________________
> > Chat with friends online, try MSN Messenger: http://messenger.msn.com
> >
> >
> > --
> > To unsubscribe, e-mail:
><mailto:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
><mailto:struts-user-help@jakarta.apache.org>
> >
>
>
>--
>To unsubscribe, e-mail:   
><mailto:struts-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: 
><mailto:struts-user-help@jakarta.apache.org>




_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com


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


Mime
View raw message