This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
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.
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.
Customer surveys are for companies who didn't pay proper attention to begin with.