tags:

views:

446

answers:

2

I am more curious about whether this is a best practice or should be avoided. Say I have two EJBS that each work with a different type of object, a widget and a foo. The EJB that manages widgets needs to get a collection of foos to do some processing. This functionality is already created in the FooManager bean.

The method in the WidgetManager is being created whereas the FooManager methods are already created.

Here is an example of what I mean. This is a brief example.

@Stateless
public class FooManager implements FooManagerLocal, FooManagerRemote
{
   public List<Foo> getAllFoosForAWidget(widgetId)
   {
      //runs queries and builds foo list 
   }

   public Boolean isWidgetCloseable(widgetId)
   {
     //a widget is closeable if all foos for that widget are set to "done"

     List<Foo> foos = getallFoosForAWidget(widgetId);
     boolean isCloseable = false;
     //process foos and update isCloseable respectively
     return new Boolean(boolean);

   }

}

@Stateless
public class WidgetManager implements WidgetManagerLocal, WidgetManagerRemote
{
   public void closeWidgetIfFoosAreDone(widgetId) //needs to do stuff with foos
   { 
      //generate the widget based on widgetId
      Widget widget = find(Widget.class, widgetId) 


      //is this appropriate?
      //beans are gathered through our own beanclient
      FooManager fooManager = BeanClient.getBean(FooManager.class);
      if(fooManager.isWidgetCloseable(widgetId)
      {
         widget.setStatus(Close);
         save(widget); //save widget back to database
      }
   }
}

My question is that should the WidgetManager bean call the already created methods in the FooManager bean? Should the client check to see which widgets can be closed and then send a list of the Ids to the WidgetManager?

I'm leaning toward the latter situation so that the EJBs don't have to worry about calling each others methods. The client can utilize them and just needs to send a list of ids.

+2  A: 

I would leave simple 'close' method in WidgetManager. In that way it will be less tight with foo's.

So just in some other Business Bean you will inject this two beans and will build your logic.

@Stateless
class SomeBusinessProcess implements ISomeBusinessProcess
{
   @EJB FooManagerLocal fooManager;
   @EJB WidgetManagerLocal widgetManager;

   public void process(WidgetId id)
   {
      if (fooManager.isClosable(id))
            widgetManager.close(id);
   }
}

In that way you will have more freedom and your Manager beans will be more clear.

Mykola Golubyev
+1  A: 

The above pattern is called Service Facade and is nicly discussed here: http://www.adam-bien.com/roller/abien/entry/why_service_isn_t_a

Mateusz Mrozewski
Honestly the description is not complete and kind of abstract.
Mykola Golubyev