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: RFD: RecordMappers, Peers and MapBuilders
Date Tue, 17 Jul 2012 08:41:20 GMT
Thomas Vandahl wrote:

> On 16.07.12 09:44, Thomas Fox wrote:
> > Am I right that you are addressing two different points here ?
> > 1) Whether or not we need the Peer, RecordMapper and MapBuilder classes
> > different classes ?
> > 2) Whether or not to generify the BasePeerImpl class ?
> The general goal was simplification, but basically, yes.
> > So, when there was the wish to concentrate the explicit database
> > information, I'd concentrate it in the peer class and not in the
> > RecordMapper class (as there is not yet this info, and it also is not
> > meaning of the class).
> I agree. I didn't want to propose a specific implementation. I just
> noticed that
> - we generate up to 12 classes per table (BaseXXX, XXX, BaseXXXPeer,
> XXXpeer, BaseXXXPeerImpl, XXXPeerImpl, BaseXXXRecordMapper
> XXXRecordMapper, BaseXXXManager, XXXManager, XXXMapBuilder and XXXBean)
> - I wanted to simplify the LargeSelect interface and found that no
> single class provided all the information I needed.
> So I thought we should think about reducing complexity (for the user,
> that is) and the sheer number of classes to be generated.
> > There is no hard reason I am aware of why we can not concentrate all
> > functionality in one class. The main soft reason is that we now have a
> > separation of concerns in different classes. On the other hand,
> > concentrating the classes would mean a simpler class structure. My
> > would be to leave the class structure as it is, but I'd also be ok with
> > different decision.
> I'd like to vote for a simpler class structure. If I understand your
> concept correctly, it should be no problem to concentrate the generated
> code into one or two classes.

Probably we can add the MapBuilder's methods as protected methods to the
Peer class, without even changing the Peer public interface. On the first
look, this looks like a good idea, and the public API stays the same for
the Peers, so it's better for the user (less generated classes) (and in my
opinion, the additional two or three protected methods in the generated
peers do not make the class too complicated.

This still leaves 12 classes per table (you forgot XXXBaseBean :-)) (well,
but, being honest the default case is 8, which is not much better). I do
see your "it's complicated" point, but I do not know what to do:

Thinking again about dissolving the RecordMapper into the PeerImpl class,
this would add one public method (and a bunch of protected methods, one for
each column) to the PeerImpl class. Which is again probably acceptable for
the user, but adds still more complexity to the peers.
Dissolving the RecordMapper into the PeerImpl class is also problematic
because the Data Object classes can have protected getters and setters for
some fields (whenever the user sets protected="true" on a column), so the
RecordMapper must be in the same package as the data object class. We also
cannot make it protected because the peer class can be in another package
(at the moment).

Regarding the Peer and PeerImpl classes, of course we can go back to just
static methods, with all their problems (e.g. cannot be exchanged on
runtime, e.g. for unit testing).
We could also look at a compile-time switch to generate either just static
methods or impl classes, (but we have a lot of switches already, which does
not make testing easier).

What are your opinions ? I'm undecided.


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

View raw message