db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <fisc...@seitenbau.net>
Subject RE: Peer Class and associated fun
Date Sat, 24 Sep 2005 06:47:44 GMT




Hi Brandon,

You can use the reflection API for that.
If you want to use a String as a name, you can use
Class.forName("your.target.package." + name).instance(), and set name to
"Book", you can get an instance of Book, and proceed like you do. You might
even be able to use Class.forName("your.target.package." + name
+"Peer").getMethod(...) to execute the doSelect of the peer directly
without creating an instance of Book.

HOWEVER, personally I am not sure whether your approach makes sense. Each
time you use the reflection approach, you lose type safety. The deeper you
bury the generation in your framework, the more difficult is it to find the
cause for class cast exceptions and the like. Also, you cannot use IDE
features like "refactore" and "search references" any more, because your
binding is too loose.

Of course, you have introduced additional flexibility of the classes which
you can produce with one method. But In practice, I personally have never
missed such flexibility. Usually, I know that I want to read books in a
place, and therefore I can also write "BookPeer.doSelect()" instead of
"GeneralObjectRetriever.retrieve()". If this is not flexible enough for
you, you can try Torque's inheritance mechanism (no idea how good it works,
never used it myself). If this is still not flexible enough, well, then you
have to do something like you plan to do.

Again, this is just my personal experience and opinion, and might not at
all be applicable to your specific situation.

           Thomas

"Brandon" <eff4eye@hotmail.com> schrieb am 23.02.2005 20:27:28:

> In order to simply the Torque programming model even further, I am trying
to
> create CRUD methods for a database that will essentially do the stuff
that
> I'm requesting for me.  That way instead of writing all of this stuff for
a
> retrieve everytime, I just call a generic method retrieve() and it
returns
> what I wanted to select on from the database.  So I've noticed that all
of
> my auto-generated databases implement this interface called Persistent.
> This is essentially the way I see things going right now:
>
> retrieve (Persistent p)
> {
>     retrieve (p, null);
> }
>
>
> retrieve (Persistent p, Map m)
> {
>     // create a criteria here
>     // if m != null then go through a for loop that iterates through the
map
> and adds to
>     // the criteria object
>     return ((BaseObject)p).getPeer.doSelect(criteria);
> }
>
>
> This seems to simplify things a bit, but I think that passing in a String

> rather than a Persistent makes much more sense.  It just seems akward to
> program this way.  Using the example database the tutorial provides, in
> order to perform a statement equivalent to "select * from book;" one
would
> have to pass in a new Book object to retrieve.  Essentially the call
would
> look like "List bookList = retrieve(new Book());" and I think it makes
much
> more sense to do something like "List bookList = retrieve("Book");".
Does
> anyone know how I could accomplish something like this or am I stuck
passing
> in a new Book object?
>
> -Brandon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org
>


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


Mime
View raw message