struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Delamere" <h...@michael-delamere.de>
Subject Re: Architecture advice....
Date Mon, 29 Jul 2002 22:09:45 GMT

----- Original Message -----
From: "David Graham" <dgraham1980@hotmail.com>
To: <struts-user@jakarta.apache.org>
Sent: Monday, July 29, 2002 11:51 PM
Subject: Re: Architecture advice....


> Sorry Michael, it seems that I've confused the issue with this factory
> method business.  Forget everything about the factory, just make one
facade
> class (call it ServiceFacade) that hides your other service objects (which
I
> showed in the last post) and has this code to get the singleton instance:
>
> public class ServiceFacade{
> private ServiceFacade instance = new ServiceFacade();
>
> // protect constructor so clients must go through getInstance()
> protected ServiceFacade(){
>
> }
>
> // get the singleton instance of the facade
> public static ServiceFacade getInstance(){
>   return instance;
> }
> ...
>
> That should be what you're looking for.  Now, in case you care about this
> other factory stuff you can look in the Design Patterns book by Erich
Gamma
> et al. for these patterns "Abstract Factory", "Factory Method", and
> "Facade".
>

Thanks,

now I _really_ do understand what you are getting at.  That´s the way I
think.  Incidentally, I have had a design pattern book open all along whilst
reading everybodies replies and am well aware of what is being discussed :-)

Thank you very much!

Regards,

Michael



> >see below:
> >
> >----- Original Message -----
> >From: "David Graham" <dgraham1980@hotmail.com>
> >To: <struts-user@jakarta.apache.org>
> >Sent: Monday, July 29, 2002 11:11 PM
> >Subject: Re: Architecture advice....
> >
> >
> > > 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
> > > }
> > > }
> >
> >That was actually our general idea; i.e. to use a kind of facade you
> >describe here.  The problem we were faced with was how we would implement
> >it.  The two major ideas were to use static methods or normal classes but
> >creating many instances didn´t seem like the solution.  That´s why I
quite
> >liked your singleton idea.
> >You also suggested using some kind of a factory which would be something
> >like ServiceFactory.getInstance();  I thought that this would be a way to
> >check if the instance already existed or not, and return one accordingly.
> >Are you now talking about the facade pattern without the singleton
concept?
> >
> >
> >
> > >
> > > 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.
> > >
> >Yes.  I like it :-)
> >
> > > 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.
> >
> >Just to be really ackward:  what if the facade consisted of singletons
> >which
> >were returned by a factory?  Would that be an option or is that not
ideal?
> >Sorry but I´m just trying to get the picture and you started with the
idea
> >:-).
> >
> > >
> > > I hope this helps.
> > >
> >
> >Yes, thank you very much.  I think this will be the last set of questions
I
> >have for you.
> >Thanks for your time.
> >
> >Regards,
> >
> >Michael
> >
> > >
> > > >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>
> > >
> >
> >
> >--
> >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>
>


--
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