Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Introspection on entity beans  RSS feed

 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Greetings,
I don't have access to an server right now and I can't figure it out by scrutinizing my books. My question is: if, within a method of an entity bean, an Introspector is used on 'this.getClass()', would it give me the actual Method objects for all the get/set methods so I can invoke them generically?
I know it can be done on the remote/local interface objects, but how about on the bean itself?
kind regards
 
Simon Brown
sharp shooter, and author
Ranch Hand
Posts: 1913
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I'm pretty sure that it would do since it shouldn't matter whether the actual bean implementation or a server generated class was being used behind the scenes. What is it you're trying to achieve? If you don't mind me asking, of course.
Simon
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Simon Brown:
What is it you're trying to achieve? If you don't mind me asking, of course.
Simon

I'm trying to get rid of those hundreds of stupid DTO (Data Transfer Objects) by simply introspecting the bean (canibalizing the java.bean.Introspector class) for its persistent properties. It would be nice to be able to walk a simple Set object for the property names and returning a simple HashMap containing the attribute name/value pairs. I know that this works (using the local/remote interfaces), but this scenario causes loopback problems (where the beans have to be reentrant and where the transaction stuff goes berzerk).
thanks for your reply and
kind regards
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Look, those of us who originally came up with the idea of DTO's (Martin Fowler, John Crupi and myself in particular) considered this idea and explicitly rejected it because it causes more problems than it solves! In particular:
(1) A Hashmap can't implement any behavior. Where are you going to put your data validation logic?
(2) A Hashmap doesn't have an external interface -- are you just going to say you always have the SAME interface (all the exact same fields) as your Entity beans? What if your Entity bean has 100 fields taken from a database? What if you only need 10 of them -- are you always going to schlep around the other 90? Are you certain you want the data to be represented the same? What about data conversion (merging a FNAME and LNAME into a name or changing an int to a String or vice versa?)
(3) You can't look at a Hashmap at compile time and tell what it contains -- you have to rely on some sort of meta-data (like the Remote or Local Interface, in this case) and the problem is those things change. What if you get version creep between your client and server? There would be no way to discover that or deal with that -- on the other hand Serialization would let you know something changed...
A better option is to spend your time (and your effort) on building a tool to introspect on the bean and generate DTO code. Or just use one of the dozens of tools already out there (commercial and open-source) that already do that...
Kyle
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Excellent post Kyle.
Just to chime in, XDoclet is one of those products that Kyle is referring to. XDoclet will generate the deployment descriptors, home and remote interfaces, and DTOs for your EJBs. Very nice product and it is open-source.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!