• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Confused, create this method ??

 
clojure forum advocate
Posts: 3479
Mac Objective C Clojure
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey all.
assume we have two CMP beans TeamBean, PlayerBean
the relationship is one to many and bidirectional.
TeamBean has the following CMP fields:
name, city
TeamBean has setter and getter methods for these fields.
the database schema for TeamBean is :
NAME, CITY
PlayerBean has the following CMP fields :
id, email
PlayerBean has setter and getter methods for these fields.
the database schema for PlayerBean is :
ID, EMAIL, TEAM (TEAM is FK)
I have the following code (in a facade bean):

the container will insert "a right" value at TEAM column of Player table.
but I have read some articles that said :
we should a CMP field called team in PlayerBean and create setter and getter methods for this CMP field.
this is because (as the article says), we want to create a transfer object for PlayerBean with these fields :
id, email, team
so we able to write :
new PlayerDO(local.getID( ), local.getEmail( ), local.getTeam( ));
in my case (which I didn't create getTeam( )), I can write :
new PlayerDO(local.getID( ), local.getEmail( ), local.getTeamLocal( ).getName( ));
what is the right approach ??
as far as I know, if we create a method like setTeam( ), this may damage the mapping that has been done by the container.
should I create a CMP field called team and create setter and getter methods for it ?
 
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by John Todd:
we should a CMP field called team in PlayerBean and create setter and getter methods for this CMP field.


You've done that (partially) already: setTeamLocal(TeamLocal) is that accessor. And with CMP/CMR, you only declare abstract accessors -- not the member fields to hold their values.

With regard to data objects (e.g. PlayerDO), you can create helper classes that will create DOs from your entity beans, and this is what the article was getting at, I believe. I took a short-cut and added DTO-creation methods to my entity beans directly: getAllFieldsDTO and getWholeTreeDTO. As the second method's name implies, my solution is quite inflexible, but it was quick to implement and works.Realize that PlayerLocal.getTeam (getTeamLocal in your case) returns the entity bean's interface, which you don't want to put directly into your DO. Your code would look more like this:
 
Hussein Baghdadi
clojure forum advocate
Posts: 3479
Mac Objective C Clojure
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for greate help.
please not that I wrote :
new PlayerDO(local.getID( ), local.getEmail( ), local.getTeamLocal( ).getName( ));
I think it is still working, right ?
thanks again.
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by John Todd:
please not that I wrote :
new PlayerDO(local.getID( ), local.getEmail( ), local.getTeamLocal( ).getName( ));


Yes, I hadn't noticed that the team's name was its primary key. So the above line would be a complete PlayerDO. The code I wrote was to create a TeamDO that a PlayerDO wraps.

The way I built my DTOs, each DTO can contain any number of lists of other DTOs to support one-to-many relationships. Any sub-DTOs that get added/modified/deleted will be so modified in the database when the root DTO is persisted.
 
reply
    Bookmark Topic Watch Topic
  • New Topic