> > Putting the actions and data in the same class or not is > really just a > > matter of preference. > Ah ok, i also saw designs where a bean had an action method. > I didnt liked this.I think actions should go into an own > class (Action > class) > This is one point i dont want to change.
This goes towards Jeff's statement of following an OO design. Separating a bean by methods (basically a POJO) and a separate object for action is the OO design violation. This has nothing to do with whether an object is stateful or stateless, it has to do with tying an action directly with the bean it impacts.... Your managed beans are free to defer business logic to a separate layer (and that is a position that I fully support, endorse, and enforce implementation under), but from the JSF perspective it is only working against the managed beans and not the business layer. So, you have this GroupsListBean which sounds like it is responsible for managing a groups list. The GroupsListBean probably has getters/setters on the group list, but in our environment it would also have action methods to do things like select a group for display/edit, an action to delete a group from the list, add a group to the list, whatever. The JSF is simpler because it is accessing the GroupsListBean for not just fields, but also supported actions against that list. The managed bean defines the contract that the JSF can use with the list. Internally, the managed bean (in this case the GroupsListBean) would defer to an actual object that implements the business logic for deleting the group, adding the group, etc. The managed bean itself might handle the navigation from the list page to a detail page for display/edit, but this is appropriate because it is strictly presentation logic and not really a business logic function.
