Originally posted by Florian Fogl:
How do I manage 1:n and n:n relationships in an entity bean? Let's say we have a table named 'customer' and a table named 'addresses' and each customer can have several addresses. So if I want to create a list in the browser of all customers with thier addresses grouped by customers do I have to iterate through all the customer bean instances and the instances of the addresses? And how do I handle n:n relationships?
The CMP engine takes care of the relationships once you have defined them in your deployment descriptor (and have the corresponding setAddresses(Collection c) etc methods in your Java interface).
Originally posted by Florian Fogl:
Do I put any business logic in the entity beans or is it better to code it in session beans? Let's say I want to delete a customer: does that mean that a session bean deletes all addresses connected to the customer or does the customer bean delete the addresses itself?
You should keep business logic out of the entity bean unless you have a specific reason for doing that. Regarding the cascading delete, see EJB 2.0 specification chapter 10.3.4.
Originally posted by Florian Fogl:
How does a stateful session bean keep track of a web session? After a JSP has been executed you lose the reference to the instance of the session bean, right? How do I know which one it was? Is there I primary key for stateful session beans?
The stateful session bean does not keep track of a web session. The web session keeps track of the stateful session bean. In other words, you need to store the Handle (a kind of "primary key") of your stateful session bean into HttpSession for later reference.
Originally posted by Florian Fogl:
How do I transfer data from the database to the entity bean? Using a resultset means that the entity bean has to have a direct connection to the database since a resultset is not serializable and can't be passed over RMI.
You access data from within the entity bean. If you're using BMP, you write the JDBC/SQL code into the relevant ejbXXX methods. If you're using CMP, you write the EJB-QL code into a deployment descriptor and let the EJB container generate the JDBC/SQL code behind the scenes.
Originally posted by Florian Fogl:
Would a DAO be a normal Java class or could it also be implemented as session bean?
The DAO
pattern is usually implemented using plain old Java objects, although you could use a session bean behind the scenes to hold the data access logic.
Originally posted by Florian Fogl:
As you can see I am a little bit confused about the possibilities and to be honest I don't really see the advantages using EJB. Transaction handling can be done without it and when I first tried to iterate through some instances of an entity bean it took ages in comparison to a simple SQL query.
Basically it comes down to the question if I am missing something here. It doesn't offer something really new except a very complicated way of accessing data.
Entity beans generally suck at accessing data but they shine at abstracting data. You could try to
search this forum for discussions about the usefulness of entity beans.
And welcome to the JavaRanch!