[ACCEPTED]-JSF backing bean structure (best practices)-jsf

You might want to check this out: making distinctions between different kinds of JSF managed beans.

Here 2 is a description of the different bean types, as 1 defined in the above article by Neil Griffin:

• Model Managed-Bean: Normally session scope. This type of managed-bean participates in the "Model" concern of the MVC design pattern. When you see the word "model" -- think DATA. A JSF model-bean should be a POJO that follows the JavaBean design pattern with getters/setters encapsulating properties. The most common use case for a model bean is to be a database entity, or to simply represent a set of rows from the result set of a database query.
• Backing Managed-Bean: Normally request scope. This type of managed-bean participates in the "View" concern of the MVC design pattern. The purpose of a backing-bean is to support UI logic, and has a 1::1 relationship with a JSF view, or a JSF form in a Facelet composition. Although it typically has JavaBean-style properties with associated getters/setters, these are properties of the View -- not of the underlying application data model. JSF backing-beans may also have JSF actionListener and valueChangeListener methods.
• Controller Managed-Bean: Normally request scope. This type of managed-bean participates in the "Controller" concern of the MVC design pattern. The purpose of a controller bean is to execute some kind of business logic and return a navigation outcome to the JSF navigation-handler. JSF controller-beans typically have JSF action methods (and not actionListener methods).
• Support Managed-Bean: Normally session or application scope. This type of bean "supports" one or more views in the "View" concern of the MVC design pattern. The typical use case is supplying an ArrayList to JSF h:selectOneMenu drop-down lists that appear in more than one JSF view. If the data in the dropdown lists is particular to the user, then the bean would be kept in session scope. However, if the data applies to all users (such as a dropdown lists of provinces), then the bean would be kept in application scope, so that it can be cached for all users.
• Utility Managed-Bean: Normally application scope. This type of bean provides some type of "utility" function to one or more JSF views. A good example of this might be a FileUpload bean that can be reused in multiple web applications.

Great question. I suffered a lot with the 26 same dilemma when I moved to JSF. It really 25 depends on your application. I'm from the 24 Java EE world so I would recommend to have 23 as little business logic in your backing 22 beans as possible. If the logic is purely 21 related to the presentation of your page, then 20 it is fine to have it in the backing bean.

I 19 believe one of the (many) strengths of JSF 18 is actually the fact that you can expose 17 domain objects directly on the managed beans. I 16 would therefore strongly recommend the <:outputText value="#{myBean.anObject.anObjectProperty}" /> approach, otherwise 15 you end up making too much work for yourself 14 in manually exposing each property. Furthermore 13 it would be a bit of a mess when inserting 12 or updating data if you encapsulated all 11 the properties. There are situations where 10 a single domain object may not be sufficient. In 9 those cases I prepare a ValueObject before exposing 8 it on the bean.

EDIT: Actually, if you are going to encapsulate every object property that you want to expose, I would recommend that you instead bind UI components to the backing bean and then inject the content directly into the value of the component.

In terms of bean structure 7 the turning point for me was when I forcefully 6 ignored all the stuff I knew about building 5 web applications and started treating it 4 as a GUI application instead. JSF mimics 3 Swing a lot and therefore the best practices 2 for developing Swing applications would 1 mostly also apply to building JSF applications.

I think the most important thing with your 6 backing beans is to seperate their logics. If 5 you have a front page for a CMS system I 4 would see it as bad practice to put every 3 piece of code into one bean because:

1. The bean would turn very large eventually
2. Its easier for other people to find what their looking for if they are troubleshooting the login page, if they then can easily just look up the loginBean.java file.
3. Sometimes you have small pieces of functionality that is clearly distinct from the rest of your code, by separating this I would imagine you would make it easier on yourself to redevelop/expand this code into something bigger, when you already have a nice bean with good structure.
4. Having 1 big bean, to do it all, will make it more memory dependant if/when you have to do declarations like this MyBigBean bigBean = new MyBigBean(); instead of using the funksjonality you actually needed by doing LoginBean loginBean = new LoginBean(); (Correct me if Im wrong here???)
5. In my opinion, separating your beans is like separating your methods. You dont want 1 big method which runs over 100's of lines, but rather split it up with new methods that handles their specific task.
6. Remember, most likely someone other than you will have to work on your JSF projects aswell.

Just 2 my 2 cents regarding this even with the 1 question already marked as answered.

I might not answer your every question, because 30 few seems quite dependent on case to case.

• This 29 is fine to have a business logic in your 28 backing bean. It depends where are you coming 27 from. If you are practicing domain driven 26 design, you will be tempted to include the 25 business logic in to backing bean or may 24 be persistence logic as well. They argue 23 that why so dumb object. Object should carry 22 not just state but behavior too. On the 21 other hand if you consider traditional Java 20 EE way of doing things, you might be feeling 19 like having data in your backing bean, which 18 also can be your entity bean, and other 17 business and persistence logic in some session 16 bean or something. That is fine too.

• Its 15 perfectly fine to have single backing bean 14 for the whole page. I don't see any problem 13 with this alone. This might not look right, but 12 that depends on the case.

• Your other question 11 is far more dependent on case you are having 10 in hand. I would prefer to go domain driven 9 here, it might be appropriate to add properties 8 to the existing or otherwise create a new 7 bean for that. Which ever suits better. I 6 don't think there is any silver bullet for 5 this.

• Which properties belongs to which backing 4 bean. Well, is it not depend on the domain 3 object? Or may be the question is not that 2 clear.

Moreover, in your given code example, I 1 am not seeing any huge benefit.

I would not necessary keep only one backing 11 bean per page. It depends on functionality 10 but most of the time I had one bean per 9 page as mostly one page handle one functionality. For 8 example on a page I have a register link 7 (I will link with RegisterBean) and a shopping 6 basket link (ShoopingBasketBean).

I do use 5 this <:outputText value="#{myBean.anObject.anObjectProperty}" /> as 4 I normally keep backing beans as action 3 beans which holds data object. I don't want 2 to write a wrapper in my backing bean to 1 access the properties of my data objects.

I like to test business code without View's, so 13 I consider BackingBeans as interfaces from 12 View to Model code. I never put any rule 11 or process in a BackingBean. That code goes 10 into Services or Helpers, allowing reuse.

If 9 you use validators, put them out of your 8 BackingBean and reference them from your 7 validation method.

If you access DAOs for 6 filling Selects, Radios, Checkboxes, do 5 that always out of a BackingBean.

Believe 4 me!. You can inject a JavaBean into a BackingBean, but 3 try to inject a BackingBean into another 2 one. You will be soon in a nigntmare of 1 maintenance and understanding code.