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 21:44:53 GMT
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>


Mime
View raw message