db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fox <Thomas....@seitenbau.net>
Subject RE: Torque 4 next steps
Date Sat, 14 May 2011 17:36:51 GMT
> > - split peer classes ito normal objects plus static wrappers
> > The idea would be to make all methods non-static and rename the classes
> to
> > XXXPeerImpl. Then there would be a static wrapper class named XXXPeer
> which
> > can create an instance of  XXXPeerImpl on demand (or it can get an
> instance
> > injected). This wrapper class has the same static methods as the
> > Peer class but delegates each method call to its XXXPeerImpl instance.
> > There would be a getter and a setter for the XXXPeerImpl instance.
> > My question now is where the constants (e.g. for table name and column
> > names) should go to ? For source compatiblility, they should be in the
> > static wrapper class. Logically, they should be in the XXXPeerImpl
> > because everything should also work without using the static wrappers.
> > I do not see another solution than keeping the constants in both the
> > XXXPeer and XXXPeerImpl classes, but maybe I have missed something ?
> After more thought and a test implemetation, the PeerImpl classes need to
> have access to the other peer classes (e.g. for the doSelectJoinYYY
> methods). The easiest way to achieve this is via the other Peer's static
> wrappers (the other possibility would be an external dependency injection
> framework, which is not overwise needed and too heavyweight for our
> problem).
> So my new insight is that the implementations cannot exist without the
> static wrappers, and in this case it would make no sense to duplicate the
> static constants in the Peer and PeerImpl classes, they would stay in the
> Peer (static wrapper).
> Then, another question arose, and this is where the RecordMapper classes
> (which are responsible for converting resultSets into DB Objects) should
> reside. In the first shot when replacing village, they were made inner
> static classes of the Peer classes. Now the question is should they be
> inner classes of the Peer or the PeerImpl class, or should they be
> in their own class. As there is no reason to make them inner classes of
> either Peer or PeerImpl, my opinion is they should best be defined
> the Peers and in their own class files.
> Are there objections against committing a discussion basis to trunk or
> should I create a branch for it ?

The division between static wrappers and the implementation in Peers is now
in SVN. It should now be possible to exchange Peer implemetations by using
the setter in the respective Peer class.
If you sislike something, please email.


To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message