Nebinger, David schrieb:
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.
Ok i understood this point, to make sure ill show my current code and
the modification u suggest
Well ill show my current code
--------------------------------------------------------------------------------
//the pojo wich is an entity bean and also a managed bean
@Entity
@Table(name = "message")
public class Message implements Cloneable {
private String subject
//other fields, text etc
}
//action iterface
@Local
public interface ManageMessage {
public String newMessage();
//public String viewMessage();
//public String saveMessage();
//public String replyMessage();
//public void addReceiver();
//public void removeReceiver();
//public void acceptMessage();
//public void refuseMessage();
}
//action
@Stateless
@Name("manageMessage")
public class ManageMessageAction implements ManageMessage {
//implementation for action methods here
public String newMessage() {
}
}
--------------------------------------------------------------------------------
and now here the modified code
#####################################################################################
//the pojo wich is an entity bean and also a managed bean and also
contains the action methods to manipulate it
public class Message implements Cloneable {
private String subject
//other fields, text etc
//implementationaction method
public String newMessage() {
}
}
#####################################################################################
Well obviously this code is much smaller.
First of all in the code for the jboss seam examples u can find the
actions separated from the beans(action always marked with stateless,
beans with session scope),
it also made sense to me so in continued this approach and its maybe
required for my environment(ill check this, and post on their list the
example). I am not sure if a managed bean can contain action methods
(obviously - course it does in your environment)
This approach(the modified example above) would also eleminate my
.backend and .frontend packages course its all in one single bean.
Possible Disadvantages : the bean gets big in code
But i think ill choose this way.
Thanks for your explanation, think i understood your point.(can u
correct me pls if my modification was wrong)
Bye,
Holger
