myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holger Prause <h.pra...@gmx.net>
Subject Re: packe structure question
Date Tue, 05 Dec 2006 22:26:38 GMT
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





Mime
View raw message