What is the best managed bean design in my case?

[Ali Afroozeh]

Hi,
I have two entities say A and B. A has a one to many relationship with B. I want to produce a simple crud for my entities.
B operations must be carried out via A. For example if I want to add one B to an existing A I should do the following:
B b = new B();
a.add(b);
ADao.update(a);

Bs don't have any meaning outside A.

Here comes my question:
What is the best approach regarding the design of managed beans?
1. One managed bean for A which manages all A and B operations.
2. One managed bean for A and one managed bean for B. These managed bean are nested. AManagedBean has an Instance of BManagedBeans. (I don't know if this approach is normal or not)
3. Like number 2 but managed beans are separated and communicate vie JSF facilities.

Or there is a more straight solution here? What if B has a one to many relationship with C!

I'm waiting to hear your suggestions!

[Tim Holloway]

I think the first thing to determine is what kinds of beans you're working with. The JSF framework as it presently exists works best on managing backing beans. It's not very handy at managing datamodel or other behind-the-scenes beans.

On the other hand, the Spring Framework is good at managing datamodel, dao/service, and other non-backing JavaBeans, but it's not JSF-aware.

There's obviously room for improvement there. At present, I have 2 separate config files, one for JSF and one for Spring, and a glue bean (resolver) that links the 2. Hopefully someday someone will come up with a cleaner approach. Aside from the need to keep 2 distinct configurations, there's enough overlap between functionalities that in some cases, it's equally valid to use either of the 2 mechanisms.

Most, though not all, situations where you have a one-to-many relationship are more appropriate for Spring, especially if you have a parent/child datamodel and a service bean to manage their relationships. But that doesn't mean that there's only one solution.