Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Confused, create this method ??  RSS feed

 
Hussein Baghdadi
clojure forum advocate
Bartender
Posts: 3479
Clojure Mac Objective C
  • Mark post as helpful
  • send pies
  • 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 ?
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • 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
Bartender
Posts: 3479
Clojure Mac Objective C
  • Mark post as helpful
  • send pies
  • 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
  • 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.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!