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?

Improve this question
2
  • Related: stackoverflow.com/questions/7223055/… That article is quoted so many times here. Commented Nov 21, 2011 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] Commented Nov 21, 2011 at 15:01

1 Answer 1

Reset to default
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.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.