Re: Non-static Peers (was: Torque 4.0 plan)

Fine for that part - though a getBackend() would be useful.
You're right about "singleton" - we really want to use it as a factory class
for the peers rather than as a true singleton. We should definitely avoid
that term :-)

How about we follow the pattern Torque uses for the other generated classes
and have a generated BaseBackend and a class that extends that?
The extended class doesn't get overwritten on generation and is present to
allow extension.
Or is that overly complex?

Actually the same follows for the BasePeer. We've had a couple of occasions
where it would be been handy to extend at that level - e.g. to provide a
different
method to getConnection(). Actually the BasePeer is really a connection
manager
and some utils (I think!). Are these appropriately named? Should it be split
up?

Taking it even further you could really have a factory class providing the
backends
which implement an interface. Then the code is built against an interface
rather
that static methods. This would be a fairly significant departure for
existing codebases though

Cheers

Joe

On 02/12/06, Thomas Fischer <tfischer@xxxxxxxxxx> wrote:
> Oops, I used the swear word "singleton" ... Fortunately, I probably
> misused it. I did not mean to enforce singleton behaviour, i.e. to forbid
> the existence of more than one instance. The static wrapper would be for
> ease of usage, the Backend class for those which do not want to use static
> method at all, and for the people in between, a setter to exchange the
> backend of the static class. I have appended some sample code.
>
> Would this be ok ? Any better suggestions ?
>
>      Thomas
>
> The code would look as follows:
>
> public class SomePeer
> {
>    private static SomePeerBackend backend;
>
>    static
>    {
>      backend = new SomePeerBackend();
>    }
>
>    public static void setBackend(SomePeerBackend backend)
>    {
>      if (backend == null)
>      {
>        throw new NullPointerException();
>      }
>      this.backend = backend;
>    }
>
>    public static List doSelect(Criteria criteria)
>    {
>      return backend.doSelect(criteria);
>    }
>
>    ....
> }
>
> public class SomePeerBackend
> {
>    /** Public constructor */
>    public SomePeerBackend()
>    {
>    }
>
>    public List doSelect(Criteria criteria)
>    {
>      // do select, return results
>      ...
>    }
>
>    ...
> }
>
> On Fri, 1 Dec 2006, Joe Carter wrote:
>
> > On 30/11/06, Henning P. Schmiedehausen <hps@xxxxxxxxxxxx> wrote:
> >>
> >> "Joe Carter" <joe.carter@xxxxxxxxxx> writes:
> >>
> >> >Personally I'd just have the singleton (snip...)
> >>
> >> If you think about a singleton, please separate the singleton class
> >> and the implementation class (don't have the static getInstance()
> >> method and a possible private C'tor in the implementation). If you
> >> separate these, it is possible for projects using e.g. Spring to
> >> manage the classes through the framework.
> >>
> >> Even better, google for 'evil singleton' and read the first few
> links...
> >>
> >>         Best regards
> >>                 Henning
> >>
> >> I completely agree. Allowing plug-in frameworks to work would be the
> > ideal.
> > Giving me _any_ way to extend was my main concern.
> > I was just a bit wary of asking for too much :-)
> >
> > Cheers
> >
> > Joe
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@xxxxxxxxxxxxx
> For additional commands, e-mail: torque-dev-help@xxxxxxxxxxxxx