EJB 3.1 @LocalBean vs без аннотации

Я понимаю разницу между локальным видом, удаленным видом и видом без интерфейса. Я просто не понимаю, в чем разница между "no view" (без аннотации) и No-interface view. А также почему я должен аннотировать свой интерфейс с @Local? Что делать, если я вообще не аннотирую интерфейс, есть ли разница?

701   4  

4 ответов:

правила (по памяти):

  1. у Боба есть @LocalBean аннотация - > bean имеет вид без интерфейса
  2. у Боба есть @Local аннотация - > Боб имеет локальный вид
  3. у Боба есть @Remote аннотация - > Боб имеет удаленный вид
  4. Bean не имеет аннотаций представления, но непосредственно реализует интерфейс, который имеет аннотацию @Local - > bean имеет локальный вид
  5. Bean не имеет аннотаций представления, но непосредственно реализует интерфейс, который имеет @дистанционного аннотации -> Bean поддерживает удаленный просмотр
  6. Bean не имеет аннотаций представления, но непосредственно реализует интерфейс, который не имеет аннотаций представления - > bean имеет локальный вид
  7. Бин не имеет никакого представления аннотации и реализует никаких интерфейсов -> бин без интерфейса

Итак, используя @LocalBean и использование без аннотации вообще являются обоими способами получения представления без интерфейса. Если вы просто хотите без интерфейса, то самый простой дело не в аннотации. При условии, что вы также не реализуете никаких интерфейсов.

часть причины @LocalBean существует для добавления представления без интерфейса к компоненту, который также имеет представление интерфейса. Я предполагаю, что сценарий, самый главный в умах авторов спецификации, был тем, где у вас есть Боб, например:

@Stateless
public class UserPreferences {
    public String getPreference(String preferenceName);
    public Map<String, String> getPreferences();
}

где вы хотели бы выставить оба метода локально, но только укрупненная getPreferences() удаленно. Вы можете сделать это, объявив удаленный интерфейс только с этим метод, то просто пощечина @LocalBean в классе bean. Без него вам пришлось бы написать бессмысленный локальный интерфейс, чтобы предоставить оба метода локально.

или, если посмотреть на это по-другому, то @LocalBean существует, потому что существует такая вещь, как представление без интерфейса, и опция без аннотации существует как удобный ярлык.

125  
2012-06-05 14:32:48
  • удаленный EJBs: можно получить доступ от удаленных клиентов (клиенты, работающие на другой JVM, такие как Swing или JavaFX клиентов, которые работают на компьютере пользователя)
  • локальные EJBs: может быть только доступ из других "компонентов", работающих на том же JVM, например веб-интерфейсы, другие EJBs
  • no-interface view: то же самое, что и локальный, но без указания бизнес-интерфейса
  • нет аннотации: простой POJO, но не EJB

Local / No-interface представления более эффективны, чем удаленные EJBs, так как ссылки на объекты могут передаваться.

15  
2012-06-05 02:12:55

Я думаю, что путаница, которую вы / мы чувствуем, является результатом истории / обратной совместимости (так сказать). Я не могу найти никакой разницы (за исключением того, что спецификация. требуется реализация для создания интерфейса, если мы используем local-view)

представление без интерфейса имеет то же поведение, что и локальное представление EJB 3.0, например, он поддерживает такие функции, как вызов pass-by-reference семантика и распространение транзакций и безопасности. Однако без интерфейса не требует отдельного интерфейса, то есть все открытые методы класса bean автоматически подвергаются воздействию абонент. По умолчанию любой сеансовый компонент, который имеет пустые реализации предложение и не определяет никаких других локальных или удаленных клиентских представлений, предоставляет представление клиента без интерфейса.

блог Oracle перед выпуском EJB 3.1

6  
2012-06-05 13:34:03

если вас интересуют более технические детали, позвольте мне сказать, что на самом деле происходит.... У вас нет прямого доступа к объекту EJB, это означает, что у вас нет ссылки (адреса) фактического объекта EJB. Когда вы ищете или вводите свой EJB, контейнер предоставляет объект в качестве клиента для этого EJB (мы можем вызвать прокси или оболочку), и вы вызываете свои бизнес-методы на этом прокси-объекте. (Вот почему вы не должны использовать ключевое слово new для создания объекта EJB с класс)

теперь для каждого типа аннотации, контейнер создает различные типы прокси с различными методами и функциями.

@LocalBean (или без аннотации) Ваш прокси-объект имеет:

  • setOptionalLocalIntfProxy()
  • getSerializableObjectFactory()

@Local Вы прокси-объект использовать локальный вызов и тип com.sun.proxy так это имеет:

  • getSerializableObjectFactory()
  • isProxyClass()
  • getProxyClass()
  • getInvocationHandler()
  • newProxyInstance()

@Remote Вы объект оболочки использовать удаленный вызов и он имеет:

  • readResolve()
  • writeReplace()
  • getStub()
  • getBusinessInterfaceName()
0  
2017-07-18 10:47:34

Comments

    Ничего не найдено.
Click here to cancel reply.