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 Thu, 12 May 2011 20:03:30 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 current
> 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 class
> 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 defined
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 outside
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 ?

     Thomas


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


Mime
View raw message