Calling a Controller from a another Controller (ejbFacade Null)

[Daniel Rojas]

Hi,
Im working on a JSF app running in a glassfish server.
The thing is I have a master detail model.
So when a detail is updated I would like to recalculate some values in the master.
What I was planning to do was, create a master controller inside the detail controller. And with the master controller make the changes. The thing is when I try to use the master controller the ejbFacade is Null. I've read some things about this problem but nothing has helped, I think Im making a mistake in the design and maybe the logic must go elsewhere.
Thanks in advance for the help.

Regards,
D

[Tim Holloway]

Welcome to the JavaRanch, Daniel!

I'm not sure that anything that you're looking at here is really JSF-related, unless you're making the common mistake of thinking that JSF backing beans are MVC Controller Objects (they're not - they're slightly impure MVC Model Objects).

However, here's a scheme that's been working well for me:

Forget the crusty old "3-tier" model. These days I have more like 7 or 8 tiers - assuming you're willing to count a couple of layers on the client for AJAX support and the like as tiers. However, the tiers of most interest for you, I think are these:

A. JSF backing bean. Provides the presentation model for the UI tiers.

B. Business layer. Platform-independent business logic (where applicable). I don't always need this.

C. Persistent Data Services. Similar to the Business layer, but this layer handles complex ORM interconnections. For example, if I have a parent/child complex of entities, this layer is responsible for access and management of those objects and their interrelationships. Layers A and B work with detached ORM objects. This layer runs most of its methods as transactional and attached, returning detached objects.

D. DAO services. Although I started out with layers C and D in one big mish-mash, these days I find it cleaner to keep per-table ORM access here. This layer knows ONLY basic data access without relationships or business logic. That makes writing unit tests easier, and I've found that unit tests are a Good Thing, since ORM frameworks tend to work with interpreted query languages that cannot be validated at compile time.