I agree with Thomas F's analysis. There are three different sets of
responsibilities here. I would paraphrase them as:
PeerImpl - Manage interactions with a "table"
RecordMapper - Serves the same purpose as JDBC's ResultSetMetaData
and contain info to map SQL **QUERIES** to objects.
MapBuilders - Similar to JDBC's DatabaseMetaData - Allows code to
determine the underlying DB structure.
I think mixing responsibility in order to cut back classes would
lead to more confusion / complexity.
-----Original Message-----
From: Thomas Fox [mailto:[email protected]]
Sent: Monday, July 16, 2012 3:45 AM
To: Apache Torque Developers List
Subject: RE: RFD: RecordMappers, Peers and MapBuilders
Thomas Vandahl wrote:
> when fiddling with the LargeSelect class I stumbled across the
> necessity to add SELECT columns as well as the requirement of a
> RecordMapper. I came to think that it would be helpful to concentrate
> the information about a table and its structure into one class,
> preferably not with static methods. Currently, this information is
> distributed over three classes, the RecordMapper, the Peer and the MapBuilder.
>
> I believe that this might even help to reduce the amount of code that
> needs to be generated by using sophisticated generics. Just some
thoughts:
>
> - RecordMapper provides a List of Column objects that can be used by
> the Peer (or LargeSelect, for that matter).
> - The BasePeerImpl<T> gets a static member variable of type
RecordMapper<T>.
> - The MapBuilder could be merged into the RecordMapper, no longer
> static
> - Several PeerImpl methods could be moved into BasePeerImpl<T>
Am I right that you are addressing two different points here ?
1) Whether or not we need the Peer, RecordMapper and MapBuilder classes as
different classes ?
2) Whether or not to generify the BasePeerImpl class ?
If yes, looking at 1)
Let's consider the options we have
a) leave Peer, RecordMapper and MapBuilder as different classes
b) put the MapBuilder functionality into the RecordMapper class
c) put the RecordMapper functionality into the PeerImpl class
d) put both the RecordMapper and MapBuilder functionality into the PeerImpl
class Let's also consider what the objects are meant to be:
- RecordMapper knows how to map a Record to a Data Object
- Peer knows how to access the database table
- MapBuilder is responsible for building a Runtime representation of the
database structure. This structure is used almost exclusively by the Peer class
- (we do not consider Data objects here)
We have explicit database structure in
- The peer's static fields
- the map builder when filling the runtime structure
- AFAIK there is no explicit information about database structure in the
RecordMapper class (meaning you cannot ask at the Record mapper class and
determine which colums exist in the database columns)
There is an implicit database structure in every class we generate (e.g the
class name corresponds to a table name, or the getters and setters in the Data
object class correspond to the columns in the database)
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 the meaning of the class).
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 nice
separation of concerns in different classes. On the other hand, concentrating
the classes would mean a simpler class structure. My tendency would be to leave
the class structure as it is, but I'd also be ok with a different decision.
2) Considering the generics part, I need to play around a bit. I am using
generics only in simple ways on a daily basis and need to get familiar with the
more complicated possibilities. I agree that there could be the possibility to
move generated code into the base classes.
I Will try to play around with generics a bit in the next time (i.e. weeks,
likely) and come back with my findings. In principle, generifying BasePeerImpl
seems to be a good idea, so if you want to have a shot, please do so.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
DukeCE Privacy Statement:
Please be advised that this e-mail and any files transmitted with
it are confidential communication or may otherwise be privileged or
confidential and are intended solely for the individual or entity
to whom they are addressed. If you are not the intended recipient
you may not rely on the contents of this email or any attachments,
and we ask that you please not read, copy or retransmit this
communication, but reply to the sender and destroy the email, its
contents, and all copies thereof immediately. Any unauthorized
dissemination, distribution or copying of this communication is
strictly prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
