Benjamin,
>Let's say I have a bean named Project and a bean named Content. A
>relationship between both beans exists - a one-to-many relationship:
>one Project can have many Contents and one Content belongs only to a
>single Project.
>
>In the database this is represented by a foreign key of the
>Projects-table which the Contents-table holds. Now I'd like to have
>the following methods in the beans:
>
>ProjectBean
>- - getContents() returns Collection
>- - addContent(Content content) returns void
>- - removeContent(Content content) returns void
>
>ContentBean
>- - getProject() returns Project
>- - setProject(Project project) returns void
>
>Now since those mthods mainly perform the same thing, I'm not sure
>whether I should approach the implementation like that. Do you guys
>think I should just go along, or maybe clean things up and leave
>either the add/removeContent methods of the ProjectBean or the
>setProject method of the ContentBean? Please give me some insight to
>what you think.
It's a modeling issue: do you need or not to navigate between the content
and a project?
Else, keep in mind that navigation methods create a dependency between the
EJBs.
The design rules I apply:
Usually I try to avoid navigation methods crossing architectural packages to
simplify deployement , version control and to avoid to turn an EJB design
into a spaghetti plate. If the client need to navigate between 2 packages,
he can use a finder method on the Home.
>
>As a second (minor) question I'd like to ask, whether there is a
>general guideline when to have the remote interface of a bean as the
>method parameter or the primary key. Any insight on this would be
>great as well ...
I see 2 reasons of using PK:
1-- Performace
setProject(ProjectPK pk) do not need to load the Project EJB in memory.
But, you be aware that EJB 2.0 spec do not use PK to manage the links, but
remote references to the Bean, so that this performace optimization may turn
to an perf problem if you plan to migrate to EJB 2.0.
2-- State Management
If you use a Stateful design on the server and cache the shared state on the
server with entities, you will usually design methods with remote interfaces
as parameters.
If you design a Stateless design on the server, passing data by value to the
client (see StateHolder or ValueObject design pattern), then you will
probably use PK instead of Remote references.
Statefull:
----------
Account account = ...
Customer customer = ...
account.setOwner(customer); // Remote interface
Stateless:
----------
// Get the state
Account account = ...
AccountStateHolder ash = ...
CustomerStateHolder csh = ...
// Modify the state
ash.setOwnerPK(csh.getPrimaryKey()); // Primary key
... do other changes ...
// send back the state to the server, optimistic concurrency control.
account.setStateHolder(ash);
Naming rule I use:
I always use a suffix for the methods according to the parameters:
Account.setOwner(Customer owner)
Account.setOwnerPK(String ownerPK)
Your EJB can supply both methods, then the developer choose the best to
write his code.
Hope this help,
Thibault Cuvillier
http://www.valtech.com
Mentoring, Project delivery with skill transfer, Education
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
