I have a design related question.Lets say i have a Customer object having the following variables
   public class Customer implements Serializable{
       String firstName;
       String lastName;
       String SSN;
       String customerType;
       AddressInfo adsInfo;
   }

   public class AddressInfo implements Serializable{
       String streetName;
       String houseNumber;
       String streetDirection;
   }
In my entity layer i have 2 entity beans (BMP's actually) called CustomerEntity and AddressEntity
Lets take a case where i want to update a collection of
Customer objects .

There are 2 ways of doing this

Use a session bean to update the Customer object and related
Address object seperately.

Pros:
       Entity beans Address and Customer are not tightly
Coupled
       ID generation for the Primary key can be done in the session beans which makes the code cleaner
 
Cons :
      Session beans is just used as segrregator which involves no business logic other than the sequence in which the object has to be stored
      As all the objects are stored individually it involves that many

Second Way :
     Pass a collection of Customer objects to the Customer entity bean and that in turn looks up the Address entity beans to Store the address .

In this case the Session beans job is to create a Collection of Customer Objects and Related Address Objects according to some rules and call the Customer object creation.

I read some where that there are 2 Opinions abt looking up for another entity beans from a entity bean.

Is it a good idea to look up for another entity beans from a entity bean.


Thanx
    


       

 

hello Chandra,

In the situation you have described, it may not be required to model the Address as an Entity bean. Because it would be reasonable to assume that the Address object's life cycle is entirely controlled by the Customer object and that it has no direct access from a Remote client. Thus it would be more of a Dependent object, in which case it can be implemented as a Java class.

But if you want to implement the Address as a Bean, then there will be a remote call whenever you look up the Address bean from the Customer bean. Even if the calling and called beans are in the same VM, the call must still go through the container. So there would be performance hits in doing inter-component calls.

Thanks

-U

The reason why i kept address as a seperate bean is that
in future there may be many address like a Listing Address and i could very well use the same address bean.And also in this implementation i would be able to update the address without updating the customer by calling the address bean
directly

thanx

hi chandra,
I accept using a java class reduces scalability.
please clarify this question of mine.Why r u going for an address entity bean,when the whole data can be put within the customer bean itself.
the advantages i see r thus....
1)The amount of work u need to do to get the data from the AddressEntity bean (after having added some more field as u have pointed)is the same as the amout of work u need to do if u put the fields in the Customerentity Bean.

2)This avoids the entity->entity lookup.

3)The code will get a lot cleaner

4)Session bean that is acting as a client can continue to worr about the workflow rather than the data logic.

comment if there is something wrong in this.
-KT

This regards usage of helper or normal java classes with EJB's.

I understand that a java class would not require a remote call, but would it not reduce scalability ?

Are there any guidelines for deciding between an EJB and a java class (other than the fact that a java class cannot be called remotely). for example, if the class involved database interaction, would an ejb be better off.

Would it benefit to move stuff out of a session or entity bean and put it in a java class.

Pls clarify.

Thanks a lot
Rahul.

Hi tiruvengalam ,
the reason why i did that was.. suppose say tommorow the user wants to update the Customers Address without updating the Customer object (ie) from the db point of view the Customer table has no change (ie)the addressId remains same but the actual address content in the address table is changed /another scenario is the address entity can be used seperately also like address can be any address why should i mix it with a customer.

Its like this -- i have a Address

it can be Customers,Users or a simple plain un-associated address(like getting from a electronic TelephoneDirectory).I can do the association whenever the need arises.So i need the address entity seperately.

Is there anything wrong /or am i missing something important

I do not think it a good model to refer to another
entity bean inside an entity bean. You can encapsulate more information in an entity bean. I think it just makes
the programming model simpler and easier to debug.