Два EJB с одинаковым интерфейсом. Это хорошая практика? - PullRequest
Новая
       3

Два EJB с одинаковым интерфейсом. Это хорошая практика?

3 голосов
/ 31 июля 2011

Мой вариант использования требует, чтобы у меня была иерархия классов, как показано ниже 

public interface ServiceA{ public void doSomething();}


public abstract class AbstractClass implements ServiceA{

     @Override
     public void doSomething(){
        getMetaValue();        
        .. do common Things applicable to all EJBS...
     }

     public abstract MeataValue getMetaValue();
}

@Stateless(mappedName="EJBBeanImlJ")
public EJBBeanImplJ extends AbstractClass{
   public MetaValue getMetaValue(){
      return new MetaValue(x, y);
   }
}

@Stateless(mappedName="EJBBeanImplK")
public EJBBeanImplK extends AbstractClass{

   public MetaValue getMetaValue(){
       return new MetaValue(a,b);
   }
}

Вопросы:

  1. Это хорошая практика EJB иметь такой же интерфейс длядве реализации EJB?

  2. Видите ли вы другие недостатки в дизайне / иерархии классов?

Примечание. Мой сервер приложений Weblogic

Спасибо

Ответы [ 2 ]

5 голосов
/ 31 июля 2011

EJB - это просто особый класс.Это особенное, потому что его жизненный цикл управляется контейнером.Это просто класс, потому что он написан на Java и может реализовывать любой интерфейс и любую бизнес-логику, какую захочет.

Итак, я считаю хорошей практикой иметь несколько реализаций одного и того же интерфейса.Это позволяет отделить реализацию конкретной услуги от ее использования.Например, вы можете создать интерфейс Sender, который может отправлять некоторый контент и две реализации: EmailSender и SmsSender.Оба реализуют один и тот же интерфейс, оба являются EJB.

Единственная проблема заключается в том, что в этом случае вы не можете привязать ссылку к отправителю только через его интерфейс, а должны использовать mappedName, как вы это сделали.

2 голосов
/ 31 июля 2011
  1. Я не вижу никаких технических проблем с этим, так как вы определили разные имена для 2 EJB, должно работать ...
  2. Я не понимаю ваши конкретные требования, поэтому я могу ошибаться: Если интерфейс службы реализован в AbstractClass и не переопределен ни в одном из EJB, представляется целесообразным иметь один отдельный EJB, реализующий ServiceA.Во-вторых, вместо двух разных реализаций EJB для одного и того же интерфейса getMetaValue, я бы предпочел параметризовать интерфейс и позволить EJB решить, хочет ли он реализовать new MetaValue(x, y) или new MetaValue(a, b), например, abstract public MetaValue getMetaValue(SomeParameter param);
...