So I've been working on a fairly large project by myself for the past several months. I had to learn the ins and outs of java beans pretty quick, and I have a reasonably good understanding of how everything works (I'm sure there are still a ton of nuisances I am unaware of). I'm at the point where I am going back through my code and doing a bit of Spring Cleaning. As I am doing this, I am finding that I haven't followed any set standard for managing the beans or anything like that. I took more of a "whatever works" approach, which I am now kicking myself for.
I wanted to get some insight from people who have worked on large projects before so I can set a standard for myself as far as managing my beans go. I have done a lot of things which I look back on and think: "there is no way this is the way I should be doing it". So let me start this by throwing out some questions:
1. When should a Session Bean be used, verse a Bean with more strict scope (such as a request or view scope)? Should there be more Request and View Beans than Session Beans?
2. In a large project, with a lot of user interaction, how many Session Beans would be considered "too many"? I know that's a broad question, so I'm looking for something like: I can't imagine a program needing more than X number of Session Beans.
3. Scenario: Page 1 is configured using Bean A (let's assume Bean A is Session Scoped). Page 2 is a secured page and is configured using Bean B (let's assume Bean B is View Scoped). Bean B is determined based on content from Page 1. That's a pretty standard situation. What is the "correct" way of initializing Bean B? I know Bean B can be configured using View Parameters, but that means the information is exposed to the user and that the page content is not extremely secure (a user could skip Page 1 and go directly to Page 2 if they know the correct View Parameters). So ideally, Bean B would be configured internally. I've come up with several ways of doing this, all of which are not extremely pretty, so I'd like to know how I should be doing this.
4. Should a Bean's class be used for more than one Bean? I have a situation where I have a UserBean and a ViewUserBean, both of which are Session Scoped and use the 'UserBean' class. UserBean is the logged in user's data, while ViewUserBean is the data for the user the logged in user is looking at. For example, if the logged in User looks at the profile page of another User, that other User's data (at least, the data which should be exposed) is located in the ViewUserBean. So, essentially, UserBean and ViewUserBean are more or less represent the same thing, ie: a User. However, should they be using the same Bean class, or should they have separate Bean classes which both inherit from a third Bean class?
I think I have a ton of other questions, but I'll just start with these. If someone could point me to some sort of coding standards for Java Beans, that would be helpful too.
If those are the worst problems you have, congratulations!
The basic rules regarding JSF backing/managed beans are the same as for any J2EE app, since the JSF scopes are based on the J2EE scopes. There are a few "gotchas", but not many.
Request Scope is (almost) Completely Useless - I capitalized that because it's one of my fundamental rules of JSF. JSF is primarily about maintaining a stateful conversation between a form (web page) and the server, and the transitory nature of request scope means that state cannot be preserved over the lifetime of the conversation. So unless you really know what you're doing, avoid it.
Session Scope is the most common way to maintain extended state. There's no such concept as "too many" beans regardless of scope - the beans are collected in hash-mapped dictionaries so the main constraint is RAM. Having lots of big beans x lots of users = Need More Memory. That's one of the reasons why JSF added View Scope. View Scope is simply Session Scope, but the object is automatically deleted when you navigate to the next View instead of leaving your webapp littered with unused objects or requiring manual brute-force removal of outdated beans.
Another alternative is Flash Scope, but I find Flash Scope to be rather contrived and limited. I mostly use it for passing error information forward from one View to another.
Then there's Application scope, which is handy for keeping shared objects such as menu SelectItem collections.
And finally, there's the custom scope where you have to do the management of the beans yourself. That one isn't very common. As of JSF 2.0, it was awkward in both design and use and not especially well-documented.
Beans can (frequently should) initialize themselves via injected data (Managed Properties). If you are initializing beans based on parameters coming in from the View, that's not only less secure, it's probably less performant. The idealized JSF application keeps its data in the server and passes it around within the server, using Views only to present and edit specific properties. Generally, I'd keep a User Profile bean in Session scope and inject it into whatever beans needed it.
And no, there's no exclusivity requirement for classes, If you want to use the same class as a basis for multiple beans - even in different scopes - that's OK. You obviously would need to give the instances different names in order to keep them separate, but the total number of instances has no limit.
Which brings up a common point of confusion. A lot of people tend to think that the View Model (backing bean) for a JSF app must also be the Data Model (ORM entity) of their persistent data. That's not true. If you're using an ORM and the data model object isn't a good fit for the View, create a separate View Model object so that the MVC part of the app can operate optimally, Then when MVC hands over to business logic (the action method), the business logic can deal with the translation from UI Model to persistent Model. The actual relationships between the 2 models is up tou you. It can be as simple as a decorator façade, an aggregate, or even full-on translations and computations.
Sources may include data from the Fakebook Research Foundation with support from Gargle University