0

I just read through this question: JSF backing bean structure (best practices) and I am trying to understand when I should make a new backing bean in my application. If I have a view with registering a question should I then have a backing bean for that task, and another one backing bean for the editing of a question, and a third one for the view where I list all the questions and so on? Or, should these three views have a common backing bean?

And if I have a view and a backing bean for adding a question on the admin side, can I use the same backing bean for adding a question on the user side which has its own view since they both will do the same task?

Community
  • 1
  • 1
LuckyLuke
  • 47,771
  • 85
  • 270
  • 434
  • Related: http://stackoverflow.com/questions/7223055/distinction-between-different-types-of-managed-beans That article is quoted so many times here. – BalusC Nov 21 '11 at 14:40
  • @Hyperion it all depends (and always) depends on the application. Try to use "loose coupling" whenever possible and minimize the scope of the beans (ViewScope/RequestScope). There's no right and wrong, but once you start managing states you open the door for subtle bugs. Generally, if it makes sense in the model: do it. [This is simply my opinion, I backed myself into a corner a lot early in learning JSF and reducing scope/ordering my model made maintenance easier] – Daniel B. Chapman Nov 21 '11 at 15:01

1 Answers1

1

Recognize that you can have combinations of extension and composition. I always try to have one backing bean per page. If there are common elements on multiple pages, I'd factor those out into a common utility bean - and then have that utility bean as a member of the backing beans for each page that needs it.

ziesemer
  • 27,712
  • 8
  • 86
  • 94